Discussion Projet:Communes de France/Mise à jour automatique des données démographiques

• Pages annexes
  • Liste des exceptions de fr.wikipedia au COG (pour les noms de communes)

Débats sur la page de présentation du projet

Nouvelle page de présentation du projet

discussion temporairement close (n'hésitez pas à la rouvrir)

Je pense qu'il est temps de faire entrer un peu d'oxygène dans ce projet : que penses-tu de proposer au Projet:Communes de France de venir voir l'avancement des travaux (voire même de publier une annonce sur le bistro) ? Dans cette optique, j'ai entièrement retravaillé la page de présentation du projet pour qu'elle s'adresse aux contributeurs susceptibles de nous aider (voire à l'INSEE ou Cassini : cf. ci-dessus). Tu peux aller lire ce que j'ai écrit ici. Ce que je te propose, c'est de transformer la page actuelle en une future page sur l'avancement du projet : liste des pages existantes, modèles existants, ... Comme je ne voulais pas faire ça brutalement, je préfère te consulter.--Juju2004 (d) 7 octobre 2011 à 16:51 (CEST)

Fais comme tu le sens Juju2004. En ce moment, je ne touche pas terre. J'ai mis à jour la page de présentation en reprenant ce que tu as écrit. Au niveau du projet CDF, il vaut mieux prévoir à l'avance un exemple concret. J'ai commencé à créé les modèles que tu as mis dans la page du projet reste à les adapter. Il faudrait également que l'on précise que la porte reste ouverte pour d'autres informations que sont surtout les suivantes (c'est celles qui reviennent le plus souvent dans nos articles)

• Évolution de la population (population, variation de population, solde naturel, solde migratoire, densité, rang national)
• Structure de la population (hommes, femmes)
• Pyramide des âges de la commune et de la moyenne nationale (plus de 75 ans, 60 - 74 ans, 40 - 59 ans, 20 - 39 ans, 0 - 19 ans)
• Ménages (nombre total de ménages, ménages de 1 personne, ménages de 2 personnes, ... ,ménages de 6 personnes ou plus)

Pour ce qui est du bistrot, ce n'est pas mon élément, à toi de voir si c'est vraiment utile. amicalement--Wikialine (d) 8 octobre 2011 à 02:28 (CEST)

Pour ce qui est des données à insérer, la liste grossit au fur et à mesure, ce qui était prévisible... On peut pour l'instant se restreindre aux données utiles pour un tableau et un histogramme (là aussi, la liste se rallonge). Pour la présentation au projet CDF, j'ai mis en place un exemple concret sur la page Projet:Communes de France/Mise à jour automatique des données démographiques/Antony à partir des modèles réels (que j'ai actualisés). Je vais poster un message puis, selon la manière dont cela va évoluer, on passer éventuellement à un cercle plus large avec le Bistro. C'est parti.--Juju2004 (d) 8 octobre 2011 à 14:15 (CEST)

J'ai opéré un léger changement cosmétique (colonnes vertes...) des modèles en démonstration afin de coller aux mieux aux habitudes des membres du projet CDF. Au niveau du nombre de données suivant le succès, il y a des chances pour que le nombre augmente. Je ne veux pas trop aller vite mais il me semble qu'à moyen terme, on devra plus simplement créer une sorte de modèle {{Section démographie d'article de commune de France}} qui comprendrait le tableau, le graphique une introduction éventuelle, des pyramides des ages... A mon sens se sera l'évolution que prendra tous ces modèles. La priorité pour le moment c'est de faire aboutir le tableau et le graphique, puis faire en sorte que tous cela fonction après on verra. amicalement--Wikialine (d) 8 octobre 2011 à 23:56 (CEST)

 

Débats sur les modèles de données

Nom des pages qui conservent les données

discussion temporairement close (n'hésitez pas à la rouvrir)

Une question de vocabulaire : ce ne sont pas des bases de données que tu veux générer et utiliser ; ce sont des tables dans une BDD. Si on avait une vraie BDD structurée (ce dont on a intérêt à essayer se rapprocher ici), on aurait deux tables :

• celle des communes, avec deux champs : identifiant commune, nom commune ;
• celle des populations avec trois champs : identifiant commune, année, population.

Ici, on est obligé de diviser la seconde table en sous-tables, par commune. Finalement, le plus simple me paraît de nommer ces modèles "données" plutôt que "table de données" (long) ou "bdd" (faux). Par ailleurs, il me paraît malvenu d'inonder l'espace "Modèle" avec ces pages. La solution est d'utiliser des sous-pages.

Voici une proposition : "Modèle:Données population/<Nom commune>/évolution" et "Modèle:Données population/<Nom commune>/structure". Ça n'a l'air de rien, mais ça fait plus propre. La page "Modèle:Données population" contiendrait simplement les explications nécessaires.--Juju2004 (d) 30 septembre 2011 à 13:27 (CEST)

Essais si tu penses que c'est mieux. J'ai tenté de faire un système le plus simple possible. L'important est de garder à l'esprit que d'autres utilisateurs que nous seront peut être appelé à travailler sur ces modèles et il faudra également programmer des bots. Donc l'important est de faire un système de stockage de données simple. Ton idée semble intéressante. Du moment que à la sortie les rédacteurs n'aient juste à mettre le modèle sur l'article et à quasiment rien faire d'autres, alors le pari est gagné. Puisque les modèles seront mis une seule fois par les utilisateurs et ensuite les bots prennent le relais. amicalement--Wikialine (d) 30 septembre 2011 à 17:32 (CEST)

Sur le coup, ce n'est pas un système de stockage dont je parle, mais juste une convention de nommage pour des modèles créés automatiquement et exploités uniquement par des modèles "secondaires" ou des bots. Donc il n'y a pas vraiment d'essai à faire, juste à se mettre d'accord sur le nom des modèles de stockage créés par bot. Les rédacteurs ne me semblent pas concernés par cette convention à adopter, puisqu'ils n'utiliseront que les modèles "secondaires", comme {{Tableau Population Commune de France}} ou {{Graphique Population Commune de France}}. L'idée est d'enlever "BDD" qui est faux, et de placer tout ça, d'une manière ou d'une autre, dans des sous-pages comme on classe des documents dans des dossiers.--Juju2004 (d) 1 octobre 2011 à 10:11 (CEST)

BDD me semblait plus parlant pour les utilisateurs et le projet suisse avait en parallèle lui aussi travaillé sur un système un peu proche, du coup j'avais réussi à dégagé un petit consensus sur la nécessité d'harmoniser nos noms de modèles. Mais bon par de problème je suis d'accord pour renommer les modèles "Bdd" en modèle "Données". Par contre, simple détail, on devrait mettre une majuscule à population après le mot "Données" du genre "Modèle:Données Population" et non pas "Modèle:Données population". Pour les modèles infobox, on travail comme ça coté convention de nommage. amicalement--Wikialine (d) 2 octobre 2011 à 14:51 (CEST)

 

Structure des données

discussion temporairement close (n'hésitez pas à la rouvrir)

Évidemment, MediaWiki n'est pas conçu pour stocker des tables de données. Le switch est la solution la plus simple et la plus souple, mais pas la moins lourde pour le parser MediaWiki. Dans tous les cas, structurer les données par ligne (année/nombre) est une bonne idée a priori, mais n'apporte que de la charge supplémentaire par rapport à ceci : |année1=123|population1=456. On évite l'utilisation de #titleparts par la suite, ce qui allège l'exploitation des données par les modèles.

Je reviens sur l'autre solution :

{{{{{modèle}}}
  |année1=123|population1=456
  ...
}}

En utilisant le paramètre modèle, on transmet par ex. Tableau Population Commune de France qui exploite directement les données comme si c'était ses propres paramètres : le résultat est qu'au lieu d'avoir nombre de lignes*2 appels d'un modèle, on n'en a qu'un. On peut également écrire modèle=#switch:annéen, ce qui permet de récupérer individuellement chaque donnée. Mais on ne peut pas passer de paramètre supplémentaire au modèle {{Tableau Population Commune de France}}, ce qui est gênant si on veut le paramétrer avec une taille ou une couleur ou je ne sais quoi... Pour paramétrer, il faut créer un autre modèle, ex. {{Tableau réduit Population Commune de France}}. (Tu peux voir sur Utilisateur:Juju2004/Astuces_pour_la_programmation_des_modèles#Stockage_d.27informations, c'est peut-être plus clair.)

Il faut déterminer si ces tableaux, graphiques, etc. risquent d'être largement paramétrés ou non.--Juju2004 (d) 30 septembre 2011 à 13:33 (CEST)

Pour ce qui est de l'usage des données par ligne (année/nombre), j'avais fait ce choix car pour la programmation de mon bot en PHP c'était plus pratique et ça permettait de simplifier le fonctionnement de certains modèles. Changer cette structure peut surement être envisagé mais reste à voir ce que ça donne. Pour le nom des modèles qui accueillent les données, moi j'ai mis bdd car je pensai que ça serait plus compréhensibles pour les utilisateur. WP nous laisse peu de liberté en matière de programmation, on ne peut pas faire de table en tant que telle. Mais bon sur ce point je n'ai pas d'avis tranché, on peut changer si tu y tiens vraiment. Pour ce qui est du paramétrage des tableau (couleur taille...), à éviter. Tous les articles de communes doivent répondre aux mêmes critères de présentation (on évite des conflits d'éditions sur des choix purement subjectifs de rédacteur). Par ailleurs l'objectif est de rendre l'usage simple de ces modèles. L'utilisateur doit juste placer le modèle dans l'article sans rien avoir à remplir ou quelques détails (comme une références supplémentaire...). Le plus simple est d'avoir un modèle unique par application (1 tableau, 1 graph) autrement se sera encore des conflits absurdes. amicalement--Wikialine (d) 30 septembre 2011 à 17:19 (CEST)

Pour les données par ligne, je ne vois pas ce que ça simplifie au niveau modèle. En prenant au hasard dans {{Tableau Population Commune de France}} (sans changer le nommage pour l'instant, ni dans la simplification du modèle) :

<th scope=col>{{#ifeq:{{Bdd Population {{PAGENAME}}|1}}|{{Bdd Population {{PAGENAME}}}}
  |-
  |[[{{#titleparts:{{Bdd Population {{PAGENAME}}|1}}|1}}]]
}}</th>
...
<td style="background-color:#f3fff3;">{{#ifeq:{{Bdd Population {{PAGENAME}}|1}}|{{Bdd Population {{PAGENAME}}}}
   |-
   |{{formatnum:{{#titleparts:{{Bdd Population {{PAGENAME}}|1}}|1|2}}}}
}}</td>
...

contre :

<th scope=col>{{#ifeq:{{Bdd Population {{PAGENAME}}|annee1}}|{{Bdd Population {{PAGENAME}}}}
  |-
  |[[{{Bdd Population {{PAGENAME}}|année1}}]]
}}</th>
...
<td style="background-color:#f3fff3;">{{#ifeq:{{Bdd Population {{PAGENAME}}|année1}}|{{Bdd Population {{PAGENAME}}}}
  |-
  |{{formatnum:{{Bdd Population {{PAGENAME}}|population1}}}}
}}</td>
...

Ce qui est plus compréhensible (pas besoin de connaître le format de la ligne pour comprendre ce que fait le modèle) et qui évite l'utilisation de #titleparts. Pour le nommage, je t'ai répondu ci-dessus. Pour un modèle qui fait ce que tu veux de manière plus légère, je vais plancher sur la question.--Juju2004 (d) 1 octobre 2011 à 10:23 (CEST)

J'ai essayé d'être light dans mes explications. L'une des raisons du choix de l'usage des données par ligne (année/nombre) était en raison également de la programmation de mon bot. Voilà l'un des passages du script PHP de mon bot :

    $debut_url_wp = 'http://fr.wikipedia.org/w/index.php?title=';
    $nom_modele_pop = $array2[ $i ];
    $fin_url_wp = '&action=edit';
    $fichier_wp = $debut_url_wp.$nom_modele_pop.$fin_url_wp;
    $contexte = stream_context_create(array('http' => array('user_agent' => 'Alinebot awesome script')));
    $texte_wp = file_get_contents($fichier_wp, false, $contexte);
    preg_match('#<textarea tabindex="1" accesskey="," id="wpTextbox1" cols="80" rows="25" style="" name="wpTextbox1">(?<syntaxhighlight lang="text">[^<]+)</textarea>#i', $texte_wp, $contenu);
    preg_match('#(?<nbre0>[^<]+)\| (?<nbre1>[^<]+) = [0-9]+/[0-9]+\s* \| [0-9]+/[0-9]+/#', $contenu['source'], $contenu2);
     preg_match('#(?<nbre0>[^<]+)\| max = (?<nbre1>[^<]+)#', $contenu['source'], $contenu3);

L'usage de #titleparts peut bien entendu être écarté. On verra à la fin au moment de la création du bot. On adaptera le script. Je te laisse décidé, ce qui est le mieux. Je te suis en tout cas. amicalement--Wikialine (d) 2 octobre 2011 à 15:02 (CEST)

J'imagine que c'est le script qui doit récupérer l'ancien modèle et le mettre à jour. Deux questions me viennent à l'esprit :

1. pourquoi ne pas simplement substituer le nouveau modèle à l'ancien ? (Eventuellement après test de non identité.)
2. pour lire le modèle existant, pourquoi ne pas utiliser "action=raw" qui te donne directement le contenu de la page sous forme de texte ?

Comme c'est un bout de code, je n'ai peut-être pas tout compris... Quoi qu'il en soit, comme tu dis, le bot peut attendre : mieux vaut pour l'instant avoir une bonne structure de données.--Juju2004 (d) 2 octobre 2011 à 22:13 (CEST)

Mon objectif premier était de démontrer la faisabilité du système. C'est chose faite. Cependant, je n'ai pas tenu à développer un bot complexe. Je suis resté très basique et j'ai créé un script à la volé. Mais effectivement, il y a moyen de faire autrement, entièrement d'accord. La programmation du bot reste la dernière étape, on verra ça au moment de la programmation. Quentinv57 est également prêt à apporter sa contribution pour le développement du bot. Donc à ce niveau là, je suis confiante. amicalement--Wikialine (d) 3 octobre 2011 à 12:38 (CEST)

 

Structure des modèles Données

discussion temporairement close (n'hésitez pas à la rouvrir)

La nuit portant conseil, je me suis dit que quitte à créer plus de 36 600 modèles données autant leur donner plus d'importance en accueillant d'une part les données démographiques mais éventuellement d'autres données qui pourraient être ajoutées automatiquement. Je n'ai pas encore pris le temps de dresser une liste des données susceptibles d'être collectées automatiquement, mais à titre d'exemple tout simple, on pourrait créer un modèles du genre "Modèle:Données/Nom de la commune" et dans ce modèles on y mettrait nos paramètres pop, an, max, sources... mais aussi des paramètres du genre maire1, maire2... Bref toutes les données qui doivent régulièrement être mises à jour dans nos articles et qui pourraient éventuellement être mise à jour automatiquement. Ce serait bien de ce laisser une possibilité d'extension d'usage de ces modèles. Leur évolution ira suivant les besoins qui se feront sentir. Il n'y a pas encore de consensus ultime sur les pyramides des ages, mais il y a de très grandes chances de réussir à fédérer à ce niveau là les wikipédiens... Quand penses-tu, quitte à développer un système autant le rendre souple et extensible dans son développement ? De plus je sais que si l'on créer une multitude de sous-pages pour chaque type de données se ne sera pas forcément bien vu, alors que créer une seule page de donnée pour un article, c'est mieux vu, plus simple et ça centraliserait plus facilement les données. Il va de soit qu'il ne faudra pas en faire non plus un réceptacle pour n'importe quelle information, mais uniquement celles-ci qui sont appelées à être mise à jour régulièrement et qui sont fastidieuses à ajouter pour les rédacteurs. J'ai mis à jours des 100ènes d'articles de communes savoyardes manuellement (maires, démographie...) et j'ai décidé de jeter l'éponge au bout de quelques années car j'ai compris qu'à un moment donné, cette démarche n'était plus viable et qu'il fallait songer à une automatisation de certaines taches. A toi de me dire ce que tu en penses. amicalement--Wikialine (d) 4 octobre 2011 à 15:00 (CEST)

Pour ce qui est de faire souple, je suis d'accord. Stocker de nombreuses informations est une excellente idée... à condition de la coupler à celle de sous-page. Je ne vois toujours pas où est l'objection puisque ces sous-pages seront mises à jour par un bot. Personne n'ira jamais y fourrer son nez, alors qu'il y ait une ou dix sous-pages, je ne comprends pas le problème. Il y en a peut-être un, mais il faudrait le décrire précisément : si tu connais des discussions sur la question, je suis preneur. Il vaut mieux avoir le maximum d'informations avant de faire quelque chose. Si aucune objection sérieuse n'existe, je pense que c'est aux concepteurs de décider ce qui leur convient.

En tout cas, voici une possibilité :

• "Modèle:Données/<Nom commune>/évolution population" (le "population" est déplacé)
• "Modèle:Données/<Nom commune>/structure population" (idem)
• "Modèle:Données/<Nom commune>/..."
• "Modèle:Données/<Nom commune>/divers"
• et même, un jour peut-être, "Modèle:Données/<xyz>/<tuv>" pour un domaine qui n'a rien à voir avec les communes et auquel on n'a pas pensé.

Dans ce cas, tu ne créés que les sous-pages dont tu as besoin, pour les communes sur lesquelles tu as les infos. Ça évite de transformer WP en gigantesque base de données avec des données souvent inutilisées. Le chargement des données est assez rapide (modèle court) et selon la demande dans l'article. L'idéal...--Juju2004 (d) 4 octobre 2011 à 18:04 (CEST)

D'accord pour la forme suivante :

• "Modèle:Données/<Nom commune>/Évolution population (max,pop1,an1,pop2,an2...)
• "Modèle:Données/<Nom commune>/..."

Au moins on présente ainsi un système globale et souple qui ne se cantonne pas qu'aux communes mais à tout type d'article. On s'offre un large panel de possibilité futures. C'est ok. amicalement--Wikialine (d) 4 octobre 2011 à 21:33 (CEST)

 

Étendue des données à stocker

Bonjour à tous. Bravo pour la reprise de ce projet de bot qui j'espère aboutira. En tant qu'auteur du script Excel qui permet l'édition complète des textes, tableaux et graphiques, je vais apporter ma contribution (... dans la limite de mes moyens, un script Excel, avec du VBE et des fonctions, ce n'est pas pareil qu'une programmatin en python!!). J'ai parcouru la page et n'ai pas vu de détail sur le contenu des données à stocker pour faire tourner le bot (sauf à ce qu'il soit dans un autre page que qn'ai pas vue). Car attention, il faut certes récupérer les données de l'INSEE mais aussi stocker pas mal d'autres données déduites (des rangs de classement par exemple pour les textes). J'ajoute donc un détail sur les données à stocker ici. Juju ou wikialine le déplaceront si ils le souhaitent.Roland45 (d) 13 octobre 2011 à 06:51 (CEST)

Une base de données « Bdd Population commune » permet de fournir les données aux programmes générant les codes des données démographique de l’Infobox ou de l’intro de l’article ou de la section « évolution démographique ».

Contenu du modèle Le bot actuel comporte aujourd'hui les données suivantes :

• nom : le nom de la commune (utile lorsqu'il y a parenthèses d'homonymie) ;
• type : commune (utilisé comme charte et pour les titres) ;
• ann : la nième année ;
• popn : la population de la nième année ;
• max : la population maximale (pour le graphique) ;
• nombre : le nombre de couples année/population utilisés ;
• sourcei (i variant de 1 à 3) : les sources des données ;

Observations Pour permettre de générer le texte introductif de la section "évolution démographique", particulièrement pour prendre en compte la récente réforme du recensement, il parait nécessaire d'ajouter les données suivantes (les noms de données sont bien entendu à reprendre) :

departement	Le nom du département est utilisé de nombreuses fois dans les différents textes ou sources. Il paraitrait logique de disposer de cette donnée en clair dans la base.	Donnée non actualisable.
annee_reel_1	donne l'année du premier recensement réel post-1999. En effet depuis la réforme entrée en vigueur en 2009, les recensements des commuenes de moins de 10000 habitants se font par roulement sur une période de 5 ans, ce qui compliquement passablement la représentation des données. D'où la nécessité de connaitre le premier recensement pour en déduire ensuite les suivants (ex : 2004, 2009, 2014, 2019, etc).	Donnée non actualisable, une fois qu'elle a été renseignée.
reel_1	donne la population légale issue du recensement réel 1.	Donnée non actualisable, une fois qu'elle a été renseignée.
annee_reel_2	donne l'année du deuxième recensement réel post-1999.	Donnée non actualisable, une fois qu'elle a été renseignée.
reel_2	donne la population légale issue du recensement réel 1.	Donnée non actualisable, une fois qu'elle a été renseignée.
annee_reel_3	donne l'année du troisième recensement réel post-1999.	Donnée non actualisable, une fois qu'elle a été renseignée.
reel_3	donne la population légale issue du recensement réel 1.	Donnée non actualisable, une fois qu'elle a été renseignée.
Rang national 1999	donne le positionnement au niveau national de la population de la commune pour la dernière population légale publiée. Sert de référence pour comparaison de la population en cours jusqu'au premier recensement exhaustif post-1999.	Donnée non actualisable.
Rang national en cours	donne le positionnement au niveau national de la population de la commune pour la dernière population légale publiée.	Actualisable chaque année (et donc à mettre en fin de liste).
Rang départemental en cours	donne le positionnement au niveau départemental de la population de la commune pour la dernière population légale publiée.	Actualisable chaque année (et donc à mettre en fin de liste).
Nb communes département	donne le nombre de communes du département. Utilisé dans l'introduction de la section "démographie".	Donnée non actualisable.
Taux d'augmentation	donne le taux d'augmentation de la population par rapport au dernier recensement de référence. Pour l'instant cette année de référence est 1999, mais au fur et à mesure des recensements exhaustifs réalisés, elle va changer. Utilisé dans l'introduction de la section "démographie".	Donnée actualisée chaque année.
Recensement de référence	donne l'année du dernier recensement de référence. Pour l'instant cette année de référence est 1999, mais au fur et à mesure des recensements exhaustifs réalisés, elle va changer. En théorie chaque population annuelle publiée est bien une population légale, mais pour une cohérence de lisibilité, il est convenu de retenir un affichage dans le tableau démographique des données tous les 5 ans suivant le premier recensement exhaustif. Utilisé dans l'introduction de la section "démographie".	Donnée actualisée périodiquement (en théorie tous les 5 ans pour chaque commune, ce qui équivaut chaque année pour toutes les communes).
Source 4	donne la source INSEE des prochains recensements par commune pour un département donné (exemple)	Donnée non actualisée.
type-recens	Qualifie le dernier recensement publié pour la commune. Trois solutions : exhaustif/intermédiaire/annuel. Les deux premiers types concernent les communes de moins de 10000 habitants, le dernier celles de plus de 10000.	Donnée non actualisée.
Année max	Donne l'année pour laquelle la population de la commune a attaint le pic maximum.	Donnée en principe non actualisée, sauf si le dernier recensement publié dépasse un pic ancien. A considérer donc comme une donnée actualisable chaque année.

Bonjour Roland, la structure des modèles de données à beaucoup évolué. Juju a proposé une structure un peu différente. Le fonctionnement est le même sauf qu'à présent les modèles données prennent la forme suivante :

{{#switch: {{{1|}}}
 |max = 61761
 |source1 = http://cassini.ehess.fr/cassini/fr/html/fiche.php?select_resultat=969
 |source2 = http://www.statistiques-locales.insee.fr/Fiches%5CDL%5CDEP%5C92%5CCOM%5CDL_COM92002.pdf
 |source3 = http://www.insee.fr/fr/ppp/bases-de-donnees/recensement/populations-legales/commune.asp?depcom=92002&annee=2006
 |nombre=35
 |an1 = 1793|pop1=1223
 |an2 = 1800|pop2=1100

On a convenu d'un nouveau nom pour les modèles de données également qui prend la forme suivante : "Modèle:Données/<nom article commune>/évolution population". A présent, pour faire simple, on fait appel à des sous-pages. Tu peux voir un exemple avec Modèle:Données/Antony/évolution population. Pour ce qui est des informations complémentaires que tu énonces "Rang national", "Taux d'augmentation"... ces informations pourront être éventuellement ajoutées par la suite. Reste que la tache reste ardue, pour le moment il vaut mieux se concentrer sur le problème des recensements. La programmation du bot à ce niveau là demande du temps. Par le suite, je suis amplement d'accord on devra ajouter d'autres informations, c'est d'ailleurs prévu, la nouvelle structure des modèles de données prend d'ailleurs en compte cette considération. Je vais t'apporter d'autres explications sur ton autre message plus bas concernant les textes introductifs. amicalement--Wikialine (d) 13 octobre 2011 à 14:50 (CEST)

Bienvenue Roland. J'ai répondu sur ces points plus bas. L'idée générale est : sérions les problèmes. On va se concentrer sur les tableau et le graphique (probablement l'utilité la plus immédiate) et on étendra par la suite si nécessaire. Cordialement.--Juju2004 (d) 13 octobre 2011 à 21:10 (CEST)

Le code INSEE, point d'entrée obligé dans la Bdd

Selon mon point de vue, le bot qui créera ou actualisera les modèles de données par communes devra le faire à partir du code INSEE et non à partir du nom de la commune. Pour deux raisons. D'abord d'une année sur l'autre il peut en effet y avoir des changements de noms de communes, soit purement orthographiques (ajout ou suppression d'un trait d'union) soit suite à une décision administrative (fusion par exemple). Et puis surtout pour les problèmes d'homonymie (WP le gère avec le nom du département), la base différencie à partir du code Insee. Il convient donc d'ajouter ce code INSEE en tant que type de donnée à stocker (puisque le modèle actuel ne le contient pas).
Notez que la disparition d'une commune pose d'autres problèmes pour le bot que l'on pourra voir plus tard (mais peut-être je me trompe), que l'on entre par le code INSEE ou par le nom de la commune. Par exemple la commune Saint-Germain-Source-Seine a officiellement disparu le 1er janvier 2009 suite à la fusion avec la commune de Blessey et effectivement la base ne comporte plus de ligne correspondant à cette commune. Le graphique devra donc s'arrêter en 2007 et ne pas être actualisé alors que le texte descriptif devra quant à lui malgré tout être actualisé pour signaler cette fusion. Bon, mais pas d'affollement quand même ... en 2008 c'était la seule commune!Roland45 (d) 14 octobre 2011 à 08:00 (CEST)

J'ai par ailleurs vu que le modèle ajout_donnees.php récupère les données à partir de la page Insee de la commune ([1]), mais je suppose que cette méthode est abandonnée dès lors que l'on a le tableau Excel (qui soit dit en passant est en avance d'une année sur la page en question). A priori il faut transformer les données utilisables du tableau en une Bdd que l'on va parcourir selon l'ordre numérique des codes Insee et appeler les modèles de WP un à un.Roland45 (d) 14 octobre 2011 à 08:17 (CEST)

Ok pour partir du code INSEE (principe de l'identifiant unique). J'ai juste besoin de savoir quel nom prendre pour la commune : INSEE (il y en a deux) ou Cassini. Le code du bot (dont "ajout_donnees.php") est effectivement en cours de remaniement total pour pouvoir aller directement se servir sur les sites sources. Mais dans un premier temps, comme dit dans la section "question légale", on va se limiter à un sous-ensemble bien choisi.--Juju2004 (d) 14 octobre 2011 à 10:06 (CEST)

PS. J'ai besoin du mode de constitution du code INSEE à partir des codes région, département, etc.--Juju2004 (d) 14 octobre 2011 à 11:06 (CEST)

Merci à Père Igor pour les précisions.--Juju2004 (d) 14 octobre 2011 à 13:13 (CEST)

J'ignore pour le moment comment tu as remanier mon bot. Mais à l'origine lorsque je me suis posée la question entre le choix du nom des communes et le code insee, j'en était arrivé à la conclusion qu'il fallait utiliser à la fois les codes insee pour récupérer les données sur le site de l'Insee et faire correspondre pour chacun de ces codes insee, non pas le nom de la commune, mais le nom exacte de l'article de la commune. En effet, comme cela a été précisé plus haut, il y a parfois des homonymes... et dans ce cas là on rajoute enrte parenthèse le nom du département... Donc reste à voir niveau programmation comment concilier tout cela. Moi j'avais résolu le problème (voir exempled ans le script que j'ai mis plus haut) en créant 2 listes à savoir une liste de code insee et juste en dessous la liste des noms d'articles de communes correspondant. --Wikialine (d) 14 octobre 2011 à 20:58 (CEST)

Modèles tests

discussion temporairement close (n'hésitez pas à la rouvrir)

Je viens d'ajouter une nouvelle section dans la feuille-projet sur les modèles de Bdd pouvant servir de test : Antony + les communes du Loiret qui avaient déjà un modèle que j'ai remis au nouveau format.
J'en profite pour signaler que deux différences entre ces deux modèles :
1/ la donnée source2 : http://www.recensement-2008.insee.fr/chiffresCles.action?codeZone=45011-COM&idTheme=3 dans l'ancien modèle et http://www.statistiques-locales.insee.fr/Fiches%5CDL%5CDEP%5C92%5CCOM%5CDL_COM92002.pdf dans le nouveau. Cela donne les mêmes infos, mais l'ancien est en htm et s'ouvre immédiatement et l'autre est en pdf.
2/ Le nouveau modèle contient 35 données de population et l'ancien 36. La différence provient de l'année 2007 qui n'est pas saisie pour Antony. Selon mon point de vue il est souhaitable de disposer de cette donnée, mêm si on ne l'utilise pas. En réalité selon le principe retenu, on ne l'utilise que pour les communes qui ont eu un recensement exhaustif en 2007.
Il est important d'avoir plusieurs modèles pour tester différents cas de figures en matière de graphiques. Roland45 (d) 14 octobre 2011 à 19:06 (CEST)

J'ai rectifié la liste de modèles de données que tu as ajouté. La convention de nommage pour ces nouveaux modèles a changé. Ces modèles doivent commencer par Modèles:Données/... (voir exemple que j'ai mis dans la page du projet). Autrement tes tests sur les articles ne vont pas fonctionner... S'agissant du nombre de données dans les modèles de données, pas de soucis à ce faire. Les graphiques et les tableaux s'adaptent aux nombres de données contenu dans les modèles de données. Mais effectivement, il vaut mieux faire des tests au cas où afin de vérifier tout cela. amicalement--Wikialine (d) 14 octobre 2011 à 21:10 (CEST)

 

Générateur de modèles de données semi-automatique

Bonjour, j'ai commencer à développer un générateur de modèle de donnée semi-automatique. ça reste encore à peaufiner. Le paramètre max n'est pas encore pris en compte, je n'ai pas eu le temps de m'en occuper. J'ai mis ce générateur sur le site suivant : http://wikialine.free-h.net/index.php amicalement--Wikialine (d) 18 janvier 2012 à 14:31 (CET)

Bonjour,j'ai testé, mais mon explorateur ne restitue pas les données en tableau mais en colonne dans le formulaire, ce qui me donne in fine un résultat pas tellement heureux:

{{#switch: {{{1|}}} : max= <br/> : |source1=http://cassini.ehess.fr/cassini/fr/html/fiche.php?select_resultat=318 <br/> : |source2=http://www.statistiques-locales.insee.fr : |source3=http://www.insee.fr : |nombre=33 : |an2=1911|pop2=... : |an5=1800|pop5=160 : |an6=1841|pop6=118 : |an8=1881|pop8=... : |an9=1968|pop9=... : |an14=1793|pop14=149 : |an17=1851|pop17=... :|an19=1876|pop19=... : |an20=1962|pop20=... : |an22=1921|pop22=... : |an25=utre|pop25=

As-tu une explication ? (désolé pour la mise en page)Roland45 (d) 18 janvier 2012 à 22:06 (CET)

J'ai fait une mise à jour à l'instant. Tu as du tomber à un moment où j'étais en train de tout modifier...amicalement--Wikialine (d) 20 janvier 2012 à 20:45 (CET)

Débats sur les mises à jour et le bot

La mise à jour des données : l'outil (PHP, Python, Excel)

Je ne comprends pas l'intervention du script Excel. Le bot devrait prendre les infos depuis les sites et les traiter à la volée. Je sais bien que c'est facile à dire, mais ça semble le minimum pour que ça fonctionne correctement. Il existe des bibliothèques PHP ou Python pour lire du Excel dans un tableau. Le code du modèle est ensuite généré directement en PHP, puis sauvegardé dans WP. De toute manière, Excel n'est pas fait pour générer de longues chaînes de caractères et le résultat risque d'être inexploitable.--Juju2004 (d) 30 septembre 2011 à 13:35 (CEST)

J'ai réalisé un, bot en PHP pour récupérer les données sur le site de l'INSEE qui ensuite met directement ces données dans les bdd. Mais entre temps, j'ai croisé l'utilisateur Roland qui maitrise pas mal excel qui voulait travailler sur un script excel pour réaliser les bdd initiale... Tout cela reste à l'état d'ébauche... amicalement--Wikialine (d) 30 septembre 2011 à 17:22 (CEST)

Je me rends compte que j'ai été un peu extrémiste en ce qui concerne le traitement direct du xls (jamais simple). Mais je maintiens qu'il faut éviter d'utiliser excel pour générer du code parce qu'excel n'est vraiment pas fait pour ça. Si on part d'un fichier csv (facile à obtenir à partir d'un xls), un langage de programmation type PHP ou Python te générera sans difficulté un code. Je peux te créer le script dans un des deux langages à partir du fichier qui se trouve là : [2] (ou tout autre du même style). Ce script, tu pourras ensuite le brancher sur ton bot et le tour est joué. Si tu veux prendre des données à plusieurs sources, excel est encore plus inadapté aux besoins. Je crois que j'avais déjà croisé cette idée de générer des modèles à partir d'un xls (données de chimie ?), et que les réponses avaient été dans le même sens que la mienne. Mais je ne suis plus trop sûr de ça.--Juju2004 (d) 1 octobre 2011 à 10:36 (CEST)

Moi je suis très PHP, j'avoue ne jamais utiliser Excel, donc j'éviterai d'être catégorique sur le sujet, je ne connais pas suffisament excel pour connaître toutes les possibilités que cet outil peut nous apporter. Mais ayant croisé Utilisateur:Roland45 qui lui est très porté sur excel et qu'il a déjà développé pas mal d'applications avec, j'ai commencé à échanger des idées avec lui. Car pour le moment on est pas là. Mais une fois le graphique terminé (le tableau est quand à lui quasiment achevé) et une fois le bot de mise à jour créé. Il faudra pour autant générer automatiquement ou semi automatiquemnt les pages "Données" initiales qui seront ensuite mise à jour automatiquements. Du coup, on verra comment au mieux procéder mais PHP ou excel ou python ou que sais-je tout est bon à prendre. En effet dans cette étape de création itiniale des pages de données, il faudra entre autres récupérer les données sur le site de l'insee mais également sur la base Cassini (Par exemple http://cassini.ehess.fr/cassini/fr/html/6_index.htm)... Enfin bref, ne perdons pas trop de temps à ce niveau là car ce n'est que secondaire. In fine le plus apportant est d'adopter les choix les plus adaptés, donc on verra à ce moment là. amicalement--Wikialine (d) 2 octobre 2011 à 15:17 (CEST)

Alinebot (version d'origine)

discussion temporairement close (n'hésitez pas à la rouvrir)

Le projet ayant bien avancé sur pas mal de plans, il me semble qu'il faut se pencher sur la question du bot. Je ne connais pas le degré d'avancement d'Alinebot sur le sujet, mais je pense qu'il faudrait publier les sources pour au moins deux raisons :

• c'est la seule manière de travailler dessus de manière collaborative ;
• le bot doit fonctionner à grande échelle (autant de pages à créer de que communes en France) : il nécessitera donc une autorisation (voir Aide:Bot#Règles_d'utilisation_des_bots), ce qui implique à mon avis que les sources puissent être consultées.

Il y a deux solutions : soit les publier sur Wikipédia directement, soit ouvrir un projet chez un hébergeur type SourceForge. La seconde solution permet de travailler plus sereinement en dehors de WP, la première est peut-être plus simple à mettre en place. Qu'en pense Wikialine ?--Juju2004 (d) 9 octobre 2011 à 23:15 (CEST)

Le script PHP de (Alinebot est devenu obsolète avec le changement de structure des modèles de données, il faudra donc l'adapter. J'ai également programmé le bot pour qu'il mette à jour à l'époque uniquement le recensement de la population de 2007. Par ailleurs, mon bot a une programmation succincte qui ne prend pas en compte les erreurs, il faudra donc prévoir dans le script une sorte de production par le bot d'un rapport d'erreur que pourrait rencontrer éventuellement le bot pour certains articles. La première version de ce bot était surtout là pour démontrer la possibilité technique du système proposé ici. Il s'agissait de réussir à démontrer que l'on pouvait récupérer des informations externes sur le site de l'Insee pour ensuite les inclure dans des modèles de données qui seront lus sur les articles par des modèles génériques (graphique, tableau...). A présent, le challenge est de produire un bot beaucoup plus élaboré qui sera multitâches au départ puis dans le temps, il aura entre autre à accomplir les activités suivantes :

• Créer les modèles données (1 modèle par article de commune)
• Récupérer les données dans les sites externes comme Cassini, Insee...

Pour répondre à ta question juju, SourceForge, j'y suis allé une fois comme ça mais ce n'est pas un site que je connais bien... On devrait peut être continuer à travailler sur WP en créant pour si retrouver dans les débats une page "Discussion Projet:Communes de France/Mise à jour automatique des données démographiques/Programmation Bot". Ou si tu préfères allons sur SourceForge. De toute façon, le nombre de programmeur va être très limité je pense. Je vais contacter Quentinv57 et le projet Bot. On verra bien.

En attendant je laisse ici l'aperçu du script php de mon bot qui comme je l'ai rappelé reste extrêmement basique et qui méritera d'être totalement repris à mon sens. Mon bot est composé d'un fichier php intitulée "ajout_donnees.php" et d'un sous dossier comprenant 2 fichiers php intitulées "http.class" et "wikiapi.class". Voici les scripts :

http.class

<?php
 
// Please define a HTTP_USER_AGENT string (required to connect to MediaWiki)
define ('USER_AGENT', "CaBot Script" );
 
// by Cobi Carter
 
	class http {
		private $ch;
		private $uid;
		public $postfollowredirs;
		public $getfollowredirs;
 
		/**
		 * Our constructor function.  This just does basic cURL initialization.
		 * @return void
		 **/
		function __construct () {
			global $proxyhost, $proxyport;
			$this->ch = curl_init();
			$this->uid = dechex(rand(0,99999999));
			curl_setopt($this->ch,CURLOPT_COOKIEJAR,'/tmp/cluewikibot.cookies.'.$this->uid.'.dat');
			curl_setopt($this->ch,CURLOPT_COOKIEFILE,'/tmp/cluewikibot.cookies.'.$this->uid.'.dat');
			curl_setopt($this->ch,CURLOPT_MAXCONNECTS,100);
			curl_setopt($this->ch,CURLOPT_CLOSEPOLICY,CURLCLOSEPOLICY_LEAST_RECENTLY_USED);
			if (isset($proxyhost) and isset($proxyport) and ($proxyport != null) and ($proxyhost != null)) {
				curl_setopt($this->ch,CURLOPT_PROXYTYPE,CURLPROXY_HTTP);
				curl_setopt($this->ch,CURLOPT_PROXY,$proxyhost);
				curl_setopt($this->ch,CURLOPT_PROXYPORT,$proxyport);
			}
			$this->postfollowredirs = 0;
			$this->getfollowredirs = 1;
		}
 
		/**
		 * Post to a URL.
		 * @param $url The URL to post to.
		 * @param $data The post-data to post, should be an array of key => value pairs.
		 * @return Data retrieved from the POST request.
		 **/
		function post ($url,$data) {
			$time = microtime(1);
			curl_setopt($this->ch,CURLOPT_URL,$url);
			curl_setopt($this->ch,CURLOPT_FOLLOWLOCATION,$this->postfollowredirs);
			curl_setopt($this->ch,CURLOPT_MAXREDIRS,10);
			curl_setopt($this->ch,CURLOPT_HEADER,0);
			curl_setopt($this->ch,CURLOPT_RETURNTRANSFER,1);
			curl_setopt($this->ch,CURLOPT_TIMEOUT,30);
			curl_setopt($this->ch,CURLOPT_CONNECTTIMEOUT,10);
			curl_setopt($this->ch,CURLOPT_POST,1);
			curl_setopt($this->ch,CURLOPT_POSTFIELDS, $data);
			curl_setopt($this->ch,CURLOPT_HTTPHEADER, array('Expect:'));
			curl_setopt($this->ch, CURLOPT_USERAGENT, USER_AGENT); 
			$data = curl_exec($this->ch);
 
			global $logfd; if (!is_resource($logfd)) $logfd = fopen('php://stderr','w'); fwrite($logfd,'POST: '.$url.' ('.(microtime(1) - $time).' s) ('.strlen($data)." b)\n");
			return $data;
		}
 
		/**
		 * Get a URL.
		 * @param $url The URL to get.
		 * @return Data retrieved from the GET request.
		 **/
		function get ($url) {
			$time = microtime(1);
			curl_setopt($this->ch,CURLOPT_URL,$url);
			curl_setopt($this->ch,CURLOPT_FOLLOWLOCATION,$this->getfollowredirs);
			curl_setopt($this->ch,CURLOPT_MAXREDIRS,10);
			curl_setopt($this->ch,CURLOPT_HEADER,0);
			curl_setopt($this->ch,CURLOPT_RETURNTRANSFER,1);
			curl_setopt($this->ch,CURLOPT_TIMEOUT,30);
			curl_setopt($this->ch,CURLOPT_CONNECTTIMEOUT,10);
			curl_setopt($this->ch,CURLOPT_HTTPGET,1);
			$useragent = "CaBot Script (running on nightshade.toolserver.org)"; 
			curl_setopt($this->ch, CURLOPT_USERAGENT, $useragent); 
			$data = curl_exec($this->ch);
			// global $logfd; if (!is_resource($logfd)) $logfd = fopen('php://stderr','w'); fwrite($logfd,'GET: '.$url.' ('.(microtime(1) - $time).' s) ('.strlen($data)." b)\n");
			return $data;
		}
 
		/**
		 * Our destructor.  Cleans up cURL and unlinks temporary files.
		 **/
		function __destruct () {
			curl_close($this->ch);
			@unlink('/tmp/cluewikibot.cookies.'.$this->uid.'.dat');
		}
	}
 
?>

 

wikiapi.class

<?php
 
	/**
	 * This class is for interacting with Wikipedia's api.php API.
	 **/
	class wikipediaapi {
		private $http;
		private $edittoken;
		private $tokencache;
		public $continue = NULL;
		public $apiurl;
		private $lastedit = NULL;
 
		/**
		 * This is our constructor.
		 * @return void
		 **/
		function __construct ($wikiurl) {
			global $__wp__http;
			if (!isset($__wp__http)) {
				$__wp__http = new http;
			}
			$this->http = &$__wp__http;
 
			$this->apiurl = 'http://' .$wikiurl. '/w/api.php';
		}
 
#########################################################################################################
###################################       FONCTIONS DE CONNEXION      ###################################
#########################################################################################################

		function login ($user, $pass)
		{
			$req1 = $this->http->post($this->apiurl.'?action=login&format=php',array('lgname' => $user, 'lgpassword' => $pass));
			$req1 = unserialize($req1) ;
			$token = $req1['login']['token'];
 
			$req2 = $this->http->post($this->apiurl.'?action=login&format=php',array('lgname' => $user, 'lgpassword' => $pass, 'lgtoken' => $token));
 
			return unserialize ($req2) ;
		}
 
		function logout ()
		{
			return $this->http->get($this->apiurl.'?action=logout');
		}
 
 
#########################################################################################################
###################################           LISTES DE PAGES         ###################################
#########################################################################################################

		#########  listcategories()  #########
		##                                  ##
		## Liste toutes les catégories      ##
		######################################
		function listcategories ($continue=NULL)
		{
			$append = (!empty($continue)) ? '&acfrom='.urlencode($continue) : '' ;
 
			$x = $this->http->get($this->apiurl.'?action=query&list=allpages&aplimit=5000&apnamespace=14&format=php'.$append);
			$x = unserialize($x);
 
			$this->continue = $x['query-continue']['allpages']['apfrom'];
 
			return $x['query']['allpages'];
		}
 
 
		#########    listpages()     #########
		##                                  ##
		## Liste toutes les pages           ##
		######################################
		function listpages ($continue=NULL)
		{
			$append = (!empty($continue)) ? '&apfrom='.urlencode($continue) : '' ;
 
			$x = $this->http->get($this->apiurl.'?action=query&list=allpages&apfilterredir=nonredirects&aplimit=5000&apnamespace=0&format=php'.$append);
			$x = unserialize($x);
 
			$this->continue = $x['query-continue']['allpages']['apfrom'];
 
			return $x['query']['allpages'];
		}
 
 
		#########  listredirects()   #########
		##                                  ##
		## Liste tous les redirects         ##
		######################################
		function listredirects ($continue=NULL)
		{	
			$append = (!empty($continue)) ? '&apfrom='.urlencode($continue) : '' ;
 
			$x = $this->http->get($this->apiurl.'?action=query&list=allpages&apfilterredir=redirects&aplimit='.urlencode($apnumber).'&format=php'.$append);
			$x = unserialize($x);
 
			$this->continue = $x['query-continue']['allpages']['apfrom'];
 
			return $x['query']['allpages'];
		}
 
		#########   listbyprefix()   #########
		##                                  ##
		## Liste toutes les pages qui       ##
		## commencent par $prefix           ##
		######################################
		function listbyprefix ($prefix, $namespace = 0, $continue = null)
		{
			$append = (!empty($continue)) ? '&apfrom='.urlencode($continue) : '' ;
 
			$append .= '&apnamespace='.urlencode($namespace);
 
			$x = $this->http->get($this->apiurl.'?action=query&list=allpages&apprefix='.urlencode($prefix).'&format=php&aplimit='.$count.$append);
			$x = unserialize($x);
 
			$this->continue = $x['query-continue']['allpages']['apfrom'];
 
			return $x['query']['allpages'];
		}
 
 
#########################################################################################################
###################################         OUTILS DE RECHERCHE       ###################################
#########################################################################################################
		
		######### categorymembers()  #########
		##                                  ##
		## Liste les membres de la          ##
		## catégorie $category              ##
		######################################
		function categorymembers ($category, $continue=NULL)
		{
			$append = (!empty($continue)) ? '&cmcontinue='.urlencode($continue) : '' ;
 
			$x = $this->http->get($this->apiurl.'?action=query&list=categorymembers&cmtitle='.urlencode($category).'&format=php&cmlimit=5000'.$append);
			$x = unserialize($x);
 
			$this->continue = $x['query-continue']['categorymembers']['cmcontinue'];
 
			return $x['query']['categorymembers'];
		}
 
		#########  recentchanges()   #########
		##                                  ##
		## Affiche les RC                   ##
		######################################
		function recentchanges ($count = 10, $rcshow=null, $namespace = null, $continue=NULL) 
		{
			$append = (!empty($continue)) ? '&rcstart='.urlencode($continue) : '' ;
 
			$append .= (!empty($rcshow)) ? '&rcshow='.urlencode($rcshow) : '' ;
			$append .= (!empty($namespace)) ? '&rcnamespace='.urlencode($rcnamespace) : '' ;
 
			$x = $this->http->get($this->apiurl.'?action=query&list=recentchanges&rcprop=user|comment|flags|timestamp|title|ids|sizes&rcdir=older&format=php&rclimit='.$count.$append);
			$x = unserialize($x);
 
			return $x['query']['recentchanges'];
		}
 
 
		function search ($search,$namespace = 0,$what = 'text',$redirs = false) {
 
			$array_pages = array();
				$append = NULL;
				if (!empty($this->sroffset)) $append = '&sroffset='.urlencode($this->sroffset) ;
				if ($redirs == true) $append .= '&srredirects=1';
 
				$x = $this->http->get($this->apiurl.'?action=query&list=search&format=php&srlimit=49&srnamespace='.urlencode($namespace).'&srwhat='.urlencode($what).'&srsearch='.urlencode($search).$append);
				$x = unserialize($x); // srlimit à 49, il devrait être à 500 (bug API)
				$this->sroffset = $x['query-continue']['search']['sroffset'];
				$array_pages = $x['query']['search'] ;
 
			return $array_pages;
		}
 
 
#########################################################################################################
###################################     INFORMATIONS SUR UNE PAGE     ###################################
#########################################################################################################

		#########    embeddedin()    #########
		##                                  ##
		## Liste les pages dans lesquels    ##
		## sont inclus le modèle $template  ##
		######################################
		function embeddedin ($template, $continue=NULL)
		{
			$append = (!empty($continue)) ? '&eicontinue='.urlencode($continue) : '' ;
 
			$x = $this->http->get($this->apiurl.'?action=query&list=embeddedin&eititle='.urlencode($template).'&format=php&eilimit=5000'.$append);
			$x = unserialize($x);
 
			$this->continue = $x['query-continue']['embeddedin']['eicontinue'];
 
			return $x['query']['embeddedin'];
		}
 
 
		#########     getlinks()     #########
		##                                  ##
		## Liste les liens inclus dans      ##
		## la page $page                    ##
		######################################
		function getlinks ($page, $continue=NULL)
		{
			$append = (!empty($continue)) ? '&plcontinue='.urlencode($continue) : '' ;
 
			$x = $this->http->get($this->apiurl.'?action=query&prop=links&titles='.urlencode($page).'&pllimit=500&plnamespace=0&format=php'.$append);
			$x = unserialize($x);
 
			$this->continue = $x['query-continue']['links']['plcontinue'];
 
			//ATTENTION ! Utiliser foreach
			//return $x['query']['pages'][$key]['links'];
		}
 
 
		#########     backlinks()    #########
		##                                  ##
		## Liste les pages qui pointent     ##
		## vers la page $page               ##
		######################################
		function backlinks ($page, $filter = null, $ns=null, $continue = null)
		{
			$append = (!empty($continue)) ? '&blcontinue='.urlencode($continue) : '' ;
 
			$append .= (!empty($filter)) ? '&blfilterredir='.urlencode($filter) : '' ;
			$append .= (!empty($filter)) ? '&blnamespace='.urlencode($ns) : '' ;
 
			$x = $this->http->get($this->apiurl.'?action=query&list=backlinks&bltitle='.urlencode($page).'&format=php&bllimit=5000'.$append);
			$x = unserialize($x);
 
			$this->continue = $x['query-continue']['backlinks']['blcontinue'];
 
			return $x['query']['backlinks'];
		}
 
 
		#########     langlinks()    #########
		##                                  ##
		## Liste les interwikis de la       ##
		## page $page                       ##
		######################################
		function langlinks ($page)
		{
			$x = $this->http->get($this->apiurl.'?action=query&prop=langlinks&titles='.urlencode($page).'&format=php&lllimit=500');
			$x = unserialize($x);
 
			foreach ($x['query']['pages'] as $key => $value) {
				$iwiki = $x['query']['pages'][$key]['langlinks'];
				if (empty($iwiki))  return NULL;
 
				$langs = array();
				foreach ($iwiki as $key => $value)
				{
					$lang = $iwiki[$key]['lang'];
					$langs[$lang] = $iwiki[$key]['*'];
				}
 
				return $langs;
			}
		}
 
 
 
#########################################################################################################
###################################  INFORMATIONS SUR UN UTILISATEUR  ###################################
#########################################################################################################

		function logs ($user = null,$title = null,$limit = 500,$type = null,$start = null,$end = null,$dir = 'older') {
			$append = '';
			if ($user != null) $append.= '&leuser='.urlencode($user);
			if ($title != null) $append.= '&letitle='.urlencode($title);
			if ($limit != null) $append.= '&lelimit='.urlencode($limit);
			if ($type != null) $append.= '&letype='.urlencode($type);
			if ($start != null) $append.= '&lestart='.urlencode($start);
			if ($end != null) $append.= '&leend='.urlencode($end);
			if ($dir != null) $append.= '&ledir='.urlencode($dir);
			$x = $this->http->get($this->apiurl.'?action=query&format=php&list=logevents&leprop=ids|title|type|user|timestamp|comment|details'.$append);
			$x = unserialize($x);
			$this->continue = $x['query-continue']['logevents']['lestart'] ;
			return $x['query']['logevents'];
		}
 
 
		function usercontribs ($user,$ucstart) {
				$array_pages = array();
				$dir = 'older';
 
				$append = NULL;
				if (!empty($ucstart)) $append = '&ucstart='.urlencode($ucstart) ;
 
				$x = $this->http->get($this->apiurl.'?action=query&list=usercontribs&ucuser='.urlencode($user).'&ucdir='.urlencode($dir).'&format=php&uclimit=5000'.$append);
				$x = unserialize($x);
 
				$this->ucstart = $x['query-continue']['usercontribs']['ucstart'];
				return $x['query']['usercontribs'];
		}
 
 
		function users ($start = null,$limit = 1,$group = null,$requirestart = false,&$continue = null) {
			$append = '';
			if ($start != null) $append .= '&aufrom='.urlencode($start);
			if ($group != null) $append .= '&augroup='.urlencode($group);
			$x = $this->http->get($this->apiurl.'?action=query&list=allusers&format=php&auprop=blockinfo|editcount|registration|groups&aulimit='.urlencode($limit).$append);
			$x = unserialize($x);
			$this->continue = $x['query-continue']['allusers']['aufrom'];
			if (($requirestart == true) and ($x['query']['allusers'][0]['name'] != $start)) return false;
			return $x['query']['allusers'];
		}
 
 
		function contribcount ($user) {
			$this->checkurl();
			$ret = $this->api->users($user,1,null,true);
			if ($ret !== false) return $ret[0]['editcount'];
			return false;
		}
 
 
#########################################################################################################
###################################           WIKIPEDIAQUERY          ###################################
#########################################################################################################

		function getpage ($page)
		{
			$ret = $this->revisions($page,1,'older',true,null,true,false,false,false);
			return $ret[0]['*'];
		}
 
 
		function revisions ($page,$count = 1,$dir = 'older',$content = false,$revid = null,$wait = true,$getrbtok = false,$dieonerror = true,$redirects = false) {
			$x = $this->http->get($this->apiurl.'?action=query&prop=revisions&titles='.urlencode($page).'&rvlimit='.urlencode($count).'&rvprop=timestamp|ids|user|comment'.(($content)?'|content':'').'&format=php&meta=userinfo&rvdir='.urlencode($dir).(($revid !== null)?'&rvstartid='.urlencode($revid):'').(($getrbtok == true)?'&rvtoken=rollback':'').(($redirects == true)?'&redirects':''));
			$x = unserialize($x);
			if ($revid !== null) {
				$found = false;
				if (!isset($x['query']['pages']) or !is_array($x['query']['pages'])) {
					/*if ($dieonerror == true) die('No such page.'."\n");
					else*/ return false;
				}
				foreach ($x['query']['pages'] as $data) {
					if (!isset($data['revisions']) or !is_array($data['revisions'])) {
						/*if ($dieonerror == true) die('No such page.'."\n");
						else*/ return false;
					}
					foreach ($data['revisions'] as $data2) if ($data2['revid'] == $revid) $found = true;
					unset($data,$data2);
					break;
				}
 
				if ($found == false) {
					if ($wait == true) {
						sleep(1);
						return $this->revisions($page,$count,$dir,$content,$revid,false,$getrbtok,$dieonerror);
					} else {
						/*if ($dieonerror == true) die('Revision error.'."\n");*/
					}
				}
			}
			foreach ($x['query']['pages'] as $key => $data) {
				$data['revisions']['ns'] = $data['ns'];
				$data['revisions']['title'] = $data['title'];
				$data['revisions']['currentuser'] = $x['query']['userinfo']['name'];
//				$data['revisions']['currentuser'] = $x['query']['userinfo']['currentuser']['name'];
				$data['revisions']['continue'] = $x['query-continue']['revisions']['rvstartid'];
				$data['revisions']['pageid'] = $key;
				return $data['revisions'];
			}
		}
 
		function getedittoken () {
			$tokens = $this->gettokens('Main Page');
			if ($tokens['edittoken'] == '') $tokens = $this->gettokens('Main Page',true);
			$this->edittoken = $tokens['edittoken'];
			return $tokens['edittoken'];
		}
 
 
		function gettokens ($title,$flush = false) {
			if (!is_array($this->tokencache)) $this->tokencache = array();
			foreach ($this->tokencache as $t => $data) if (time() - $data['timestamp'] > 6*60*60) unset($this->tokencache[$t]);
			if (isset($this->tokencache[$title]) && (!$flush)) {
				return $this->tokencache[$title]['tokens'];
			} else {
				$tokens = array();
				$x = $this->http->get($this->apiurl.'?action=query&format=php&prop=info&intoken=edit|delete|protect|move|block|unblock|email&titles='.urlencode($title));
				$x = unserialize($x);
				foreach ($x['query']['pages'] as $y) {
					$tokens['edittoken'] = $y['edittoken'];
					$tokens['deletetoken'] = $y['deletetoken'];
					$tokens['protecttoken'] = $y['protecttoken'];
					$tokens['movetoken'] = $y['movetoken'];
					$tokens['blocktoken'] = $y['blocktoken'];
					$tokens['unblocktoken'] = $y['unblocktoken'];
					$tokens['emailtoken'] = $y['emailtoken'];
					$this->tokencache[$title] = array(
							'timestamp' => time(),
							'tokens' => $tokens
									 );
					return $tokens;
				}
			}
		}
 
 
		function page_empty ($title) {
 
				$x = $this->http->get($this->apiurl.'?action=query&format=php&prop=info&intoken=edit&titles='.urlencode($title));
				$x = unserialize($x);
 
				foreach ( $x['query']['pages'] as $key => $value )
				{
					if ($x['query']['pages'][$key]['length'] == 0) return TRUE;
					else return FALSE;
				}
		}
 
 
		function isprotected ($title) {
 
				$x = $this->getprotections ($title) ;
 
				if ($x[0]['type'] == 'edit' && $x[0]['level'] == 'sysop') return TRUE;
				else return FALSE;
		}
 
		function getprotections ($title) {
 
				$x = $this->http->get($this->apiurl.'?action=query&format=php&prop=info&inprop=protection&titles='.urlencode($title));
				$x = unserialize($x);
 
				foreach ( $x['query']['pages'] as $key => $value )
				{
					$x = $x['query']['pages'][$key]['protection'] ;
					return $x;
				}
		}
 
		function pages_info ($array) {
 
				$titles = '';
				foreach ($array as $key => $value)
				{
						$pn = $array[$key]['title'];
 
						$titles .= (empty($titles)) ? $pn : '|' . $pn ;
				}
 
				$x = $this->http->get($this->apiurl.'?action=query&format=php&prop=info&titles='.urlencode($titles));
				$x = unserialize($x);
 
				return $x;
		}
 
 
#########################################################################################################
###################################        ACTIONS SUR LE WIKI        ###################################
#########################################################################################################

		#########       edit()       #########
		##                                  ##
		## Edite la page $page              ##
		######################################
		function edit ($page, $data, $summary = '', $minor = true, $bot = true)
		{
			// On vérifie que l'arrêt d'urgence n'a pas été déclenché
			// if ($page != PAGE_ARRET && $page != PAGE_STATUT) $this->arreturgence() ;
 
			$params = Array(
				'maxlag' => 5 ,
				'action' => 'edit',
				'format' => 'php',
				'title' => $page,
				'text' => $data,
				'token' => $this->getedittoken(),
				'summary' => $summary,
				($minor?'minor':'notminor') => '1',
				($bot?'bot':'notbot') => '1'
			);
 
			$params['starttimestamp'] = time();
			//if ($wpStarttime !== null) $params['starttimestamp'] = $wpStarttime;
			//if ($wpEdittime !== null) $params['basetimestamp'] = $wpEdittime;
 
		## Compteur pour limiter les edits par unite de temps
		$vt = 10 ;
			$tm = ( time() - $this->lastedit ) ;
			if ( $tm < $vt ) { sleep($vt - $tm); }
			$this->lastedit = time() ; 
 
			$params['basetimestamp'] = time() ;
			$x = $this->http->post($this->apiurl,$params);
			$x = unserialize($x);
 
			if ($x['error']['code']=='maxlag') {
				preg_match ("#([0-9]+) seconds lagged#", $x['error']['info'], $flimit) ;
				sleep ( $flimit[1] ) ;
				$f=fopen('maxlag.txt','a+'); fputs($f,date('d/m/Y H:i:s')."\n"); fclose($f);
				$this->edit ($page,$data,$summary,$minor,$bot,$wpStarttime,$wpEdittime,$checkrun) ;
			}
 
 
			#var_export($x);
			if ($x['edit']['result'] == 'Success') return true;
			else return false;
		}
 
 
		#########       move()       #########
		##                                  ##
		## Dépalace la page $old            ##
		######################################
		function move ($old,$new,$reason) {
			$tokens = $this->gettokens($old);
			$params = array(
				'action' => 'move',
				'format' => 'php',
				'from' => $old,
				'to' => $new,
				'token' => $tokens['movetoken'],
				'reason' => $reason
			);
 
			$x = $this->http->post($this->apiurl,$params);
			$x = unserialize($x);
			#var_export($x);
		}
 
		#########     rollback()     #########
		##                                  ##
		## Reverte l'utilisateur $user      ##
		######################################
		function rollback ($title,$user,$reason,$token = null) {
			if (($token == null) or ($token == '')) {
				$token = $this->revisions($title,1,'older',false,null,true,true);
				print_r($token);
				if ($token[0]['user'] == $user) {
					$token = $token[0]['rollbacktoken'];
				} else {
					return false;
				}
			}
			$params = array(
				'action' => 'rollback',
				'format' => 'php',
				'title' => $title,
				'user' => $user,
				'summary' => $reason,
				'token' => $token,
				'markbot' => 1
			);
 
			echo 'Posting to API: ';
			var_export($params);
 
			$x = $this->http->post($this->apiurl,$params);
			$x = unserialize($x);
			var_export($x);
			return (isset($x['rollback']['summary'])?true:false);
		}
 
 
 
 
#########################################################################################################
###################################          AUTRES FONCTIONS         ###################################
#########################################################################################################

		// If you have an emergency button on your bot userpage :
		function arreturgence () {
				if ( ! $this->page_empty(PAGE_ARRET) )
				{
					exit("\nArrêt d'urgence du bot !\n\n");
				}
		}
 
 
	}
 
?>

 

ajout_donnees.php

<?php

include 'class/http.class.php';
include 'class/wikiapi.class.php';
$alinebot = new wikipediaapi('fr.wikipedia.org');
$alinebot->login ( 'xxxx', 'xxxx' ) ;
$resume = "essai modif";
$date= '2007';
$array1 = array(45241);// liste des codes insee
$array2 = array("Utilisateur:Wikialine/essais19");// liste des nom d'article correspondant aux codes insee
$max = count( $array1 );
for ($i = 0; $i < $max; $i++)
{
    $page_nom =  $array2[ $i ];

// Récupération du contenu des modèles avant mise à jour
    $debut_url_wp = 'http://fr.wikipedia.org/w/index.php?title=';
    $nom_modele_pop = $array2[ $i ];
    $fin_url_wp = '&action=edit';
    $fichier_wp = $debut_url_wp.$nom_modele_pop.$fin_url_wp;
    $contexte = stream_context_create(array('http' => array('user_agent' => 'Alinebot awesome script')));
    $texte_wp = file_get_contents($fichier_wp, false, $contexte);
    preg_match('#<textarea tabindex="1" accesskey="," id="wpTextbox1" cols="80" rows="25" style="" name="wpTextbox1">(?<syntaxhighlight lang="text">[^<]+)</textarea>#i', $texte_wp, $contenu);
    preg_match('#(?<nbre0>[^<]+)\| (?<nbre1>[^<]+) = [0-9]+/[0-9]+\s* \| [0-9]+/[0-9]+/#', $contenu['source'], $contenu2);
     preg_match('#(?<nbre0>[^<]+)\| max = (?<nbre1>[^<]+)#', $contenu['source'], $contenu3);
 
// Récupération des données
    $debut_url_insee = 'http://www.insee.fr/fr/ppp/bases-de-donnees/recensement/populations-legales/commune.asp?annee=2007&depcom=';
    $code_commune = $array1[ $i ];
    $fichier_insee = $debut_url_insee.$code_commune;
    $texte_insee = file_get_contents($fichier_insee);
    preg_match('#<tr>\s*<td class="tab-chiffre">(?<municipale>[^<]+)</td>#i', $texte_insee, $population);
    $pop=preg_replace('/\s/', '', $population['municipale']); 
 
// Calcul du nouveau nombre à ajouter dans le modèle population de wp pour le parser switch
    $nouveau_nombre = $contenu2['nbre1'] + 1;
  
// Comparaison de l'ancien nombre max avec la nouvelle population
    $nombre_max = $contenu3['nbre1'];

if ($nombre_max > $pop) // SI nombre max est supérieur à la nouvelle population
{
    $resultat1 = $contenu['source'];
}
else // SINON
{
    $resultat1 = preg_replace('#\| max = [0-9]+#', '| max = '. $pop.'', $contenu['source']);
}

// Repérage par regex de la dernière ligne du modèle population de wp et ajout des nouvelles informations
    $resultat2 = preg_replace('#\| [0-9]+/[0-9]+/#', '| '. $nouveau_nombre .' = '. $date .'/'. $pop .'
 | '. $date .'/'. $pop .'/', $resultat1);
 
// Conversion des entités HTML spéciales en caractères
    $resultat_final = htmlspecialchars_decode($resultat2);

// Ajout du nouveau contenu dans la variable page_contenu
    $page_contenu = $resultat_final;
    $alinebot->edit ($page_nom , $page_contenu , $resume) ;
}

?>

 

amicalement--Wikialine (d) 10 octobre 2011 à 01:24 (CEST)

Ok, je vais regarder tout ça. On verra bien si on obtient de l'aide, mais ça n'est pas indispensable : j'ai déjà programmé un bot. C'était en Python, mais on peut faire une adaptation du PHP vers le Python ou l'inverse sans difficulté : il suffit de décider. Si tu me donnes le feu vert pour prendre la chose en charge, je pense en venir à bout assez vite (surtout que ton code va servir de base de départ). Ce qu'il manque pour l'instant, ce sont les formats des données initiales (les fichiers INSEE et Cassini). J'ai mis un tableau dans ce sens sur la page de projet. Il faudrait recenser l'intégralité de ces fichiers ainsi que les données à en extraire.--Juju2004 (d) 10 octobre 2011 à 08:38 (CEST)

Après tout pour le moment, e nombre d'intervenant étant faible on peut continuer les débats techniques sur le bot ici même, ce sera plus simple et si le besoin se fait ressentir on créé une sous page. J'ai pu joindre Quentin, il est débordé en ce moment, il ne pourra pas intervenir tout de suite. On devra faire sans pour le moment. Au niveau du projet bot pas de réponses. Donc on va devoir s'y coller tout les deux dans l'immédiat. Au niveau de la programmation, j'ai quelques bases en PHP mais ça s'arrête là. Python et autre, je n'ai jamais eu l'occasion de m'y intéresser surtout par manque de temps. Par conséquent ce serait bien que l'on reprenne mon script en PHP et qu'on l'améliore comme ça, je pourrai aider un peu plus et à coté de cela, il s'agit d'une programmation en partie issue du bot de Quentin, donc si il nous rejoins en cour de route, il sera moins perdu. Qu'en dis-tu ? Au niveau des données initiales, je vais contacter Roland45, je sais qu'il s'y est pas mal intéressé à un moment donné donc on ne sais jamais on pourrait gagner du temps. A coté de ça, on peut commencer à réunir les fichiers nécessaires... amicalement--Wikialine (d) 10 octobre 2011 à 17:42 (CEST)

Ok pour du PHP (en ce moment, je passe sans arrêt d'un langage à l'autre, donc ça devrait aller). Je vais lire tes sources et voir ce que ça donne. J'aurai peut-être des questions à te poser. A part ça, bien entendu que les aides de Quentin et/ou Roland sont les bienvenues, d'autant plus que j'ai un autre projet sur le feu en ce moment (les choses se sont un peu précipitées sans que je puisse temporiser). Je vais quand même essayer d'avancer.--Juju2004 (d) 10 octobre 2011 à 22:34 (CEST)

Ne te mets pas trop de pression, on a déjà bien avancé. On n'a pas de délais à tenir. Surtout que là on arrive à l'étape la plus délicate. Il vaut mieux dès à présent s'armer de patience. Je viens de trouver sur le site de l'insee la "Liste des communes existantes au 1er janvier 2011" au format text zippé à l'adresse suivante http://www.insee.fr/fr/methodes/nomenclatures/cog/telechargement.asp Cette liste peut nous être utile. Il y a également un fichier xls zippé sur le lien http://www.insee.fr/fr/themes/detail.asp?ref_id=poplog-com&reg_id=99 permettant d'obtenir la "Population et logements par commune depuis le recensement de 1962 (1961 pour les Dom) à 1999". Je n'ai pas le logiciel excel du coup j'utilise un petit logiciel appelé Bytescout XLS Viewer mais le fichier est trop volumineux car ça bug mais le contenu semble intéressant à exploiter.J'ai mis 2 nouveaux sujets sur le bot car il me semble qu'il va falloir travailler sur 2 problématiques. amicalement--Wikialine (d) 10 octobre 2011 à 23:33 (CEST)

J'ai commencé à regarder le code et les fichiers que tu as fournis. Pour moi, pas de souci, il me faut juste la totalité des fichiers de départ, un peu d'huile de coude et ça devrait aller pour produire un bot qui fonctionne.--Juju2004 (d) 11 octobre 2011 à 22:26 (CEST)

 

Mission 1 du bot - Création des modèles données

Du coté des sources, pour faire simple, en définitive on va travailler sur 2 sources uniquement à savoir le site de l'Insee et celui de Cassini. Cela implique 2 programmations d'acquisition des données. Mais ça implique également un risque de doublon de certaines données à savoir tous les recensements à partir de 1962. J'ai étudié le site http://cassini.ehess.fr/cassini/fr/html/6_index.htm . Niveau programmation cela reste ardue mais il semble qu'il y ait moyen de récupérer les données de ce site en indiquant au bot de cliquer sur le lien intitulé "EXPORTER" en haut à droite de chaque notice communale de chaque commune. En cliquant sur ce lien, on obtient un fichier texte qui comprend à l'intérieur les dates et le nombre de population. Sur ce constat, je crois qu'il faut programmer le bot pour que dans un 1er temps, il récupère les données démographiques sur le site de Cassini mais uniquement les dates et nombre de population inférieurs à 1962. Puis ensuite dans un 2ème temps, programmer le bot pour récupérer les données sur le fichier xls du site de l'Insee qui nous donne le recensement de 1962 à 1999. Autrement on peut envisager un écrasement des données directement dans les modèles données lorsqu'il y a des données identiques, ce serait peu être plus simple à programmer. A ce moment là, on récupére d'abord toutes les données sur le site de Cassini puis ensuite toutes les données sur l'Insee en écrasant au passage les données doubles à savoir celles égal et supérieur à 1962, à étudier donc au niveau de la faisabilité. Ensuite pour les recensements supérieurs là encore il va falloir envisager une 3ème programmation d'acquisition qui devra peut être s'inspirer de la première version de Alinebot pour l'acquisition des données en n'utilisant plus de fichiers text ou xls mais directement les pages du site de l'Insee enfin bref à étudier on en est pas là. Voilà pour le moment, la méthode d'acquisition qui me semble la plus plausible. Il va de soit qu'entre temps il faudra retoucher manuellement certains modèles de données pour des communes spécifiques (dom-tom peut être, communes fusionnées...). amicalement--Wikialine (d) 12 octobre 2011 à 01:14 (CEST)

Sur Cassini, il faut prendre les données jusqu'à 1962 inclus puisque l'Insee ne fournit plus depuis deux ou trois ans que des données depuis 1968. Sinon, comme je l'ai déjà signalé, pour les communes ayant fusionné ou défusionné, le recensement Cassini jusqu'à 1990 inclus est préférable à celui de l'Insee. Père Igor (d) 12 octobre 2011 à 10:55 (CEST)

Très bien, on va essayer de prendre les données de cassini jusqu'à 1990 puis pour les autres recensements on les prendra sur Insee, ça me semble faisable. amicalement--Wikialine (d) 12 octobre 2011 à 15:09 (CEST)

La fonction EXPORTER ramène un tableau excel dénommé export65.xls toujours sur le même format. Si vous pouvez aller chercher des données dans une cellule donnée, c'est gagné. Mais autant c'est facile dans Excel direct (et pour cause) autant en php, cela me semble difficile, surtout si le fichier reste en temporaire. Mais c'est plutôt à vous de dire.Roland45 (d) 14 octobre 2011 à 19:19 (CEST)

Avec la première version de mon bot, j'ai réussi à récupérer les données affichées dans les pages du site de l'Insee. Par contre je n'ai pas eu le temps de faire des essais avec Cassini, effectivement ça me semble plus complexe. De toute façon au pire du pire, on mettra les anciens recensements de façon manuelle (à l'ancienne), l'important c'est que les nouveaux recensements soient quand à eux ajoutés automatiquement. Mais là c'est la solution ultime en cas de non réussite de programmation du bot vers Cassini. amicalement--Wikialine (d) 14 octobre 2011 à 21:17 (CEST)

Récupération des données Cassini

J'ai commencé la programmation. Pour l'instant, la récupération des données de Cassini ne semble pas devoir poser trop de problème. Es-tu sûr, Roland, que le format d'export est toujours le même ? N'y a-t-il pas un nombre variable de lignes du type "Le recensement de 1826, qui ne serait qu'une réactualisation de celui de 1821, n'a pas été retenu." ?

Pour revenir sur cette première mission du bot, le plus compliqué est de faire le lien entre l'identifiant choisi (code officiel géographique) et l'identifiant de la fiche Cassini. J'y travaille à partir des pages d'index.--Juju2004 (d) 14 octobre 2011 à 21:29 (CEST)

Format d'export : De tous les tests que j'ai faits, le format est toujours le même. Les données de population sont sur les lignes 44 à 50. Mais peut-être que ton mode de récupération ne te fait pas raisonner en lignes?Roland45 (d) 15 octobre 2011 à 08:59 (CEST)

Index d'adresse de la page Cassini d'une commune : Il s'agit en fait du numéro d'ordre dans la base Cassini. Le pb est que cette base contient un bien plus grand nombre de communes que le nombre normal car tous les anciens noms y sont. Cela va être dur de trouver le bon (celui qui est en rouge) (mais peut-être tu peux tester cette couleur dans le code source ? Peut-être suffit-il à partir du code source de croiser code géo et couleur ...?)Roland45 (d) 15 octobre 2011 à 08:59 (CEST)

La démarche prévue est la suivante :

1. constitution d'une table de correspondance code officiel géographique -> numéro Cassini
2. pour chaque code officiel géographique considéré :
   1. récupération des données INSEE ;
   2. via le numéro Cassini, récupération des données sur la fiche Cassini, probablement HTML (car la table des année/population est identifiée comme "recensement" : pas de doute sur ce qu'il faut prendre).

Comme il n'y a pas correspondance 1-1 entre le code géographique et le numéro Cassini, plusieurs cas sont à envisager :

• un numéro Cassini sans code géographique : normalement une ancienne commune fusionnée ;
• un code géographique INSEE avec plusieurs numéros Cassini : est-ce possible, ou bien seulement plusieurs noms avec le même numéro Cassini ?
• un code géographique sans numéro Cassini : est-ce possible ? (une nouvelle commune par ex.)

Il y a également des informations en doublon :

• le nom se trouve sur Cassini et l'INSEE : lequel prendre ?
• si j'ai bien compris, les années populations sur Cassini jusqu'à 1962, voire 1990 dans certains cas (cf. Père Igor) : comment identifier ces cas ?

J'ai besoin d'une confirmation de la part des spécialistes : cette démarche convient-elle ? Y a-t-il d'autres cas à traiter ? Que faire pour les informations en doublon ?--Juju2004 (d) 15 octobre 2011 à 11:13 (CEST)

Dans Cassini, une même commune peut apparaître autant de fois qu'elle a porté de noms différents (exemple en Dordogne avec la commune d'Abjat-sur-Bandiat (24 2 26 001), qu'on retrouve également sous la forme Abjat (24 2 26 001). Par contre, Abjac (24 3 40 004) et Abjat (24 3 40 004) se réfèrent à l'ancien nom d'une autre commune Ajat (24 3 40 004). L'idéal serait de ne récupérer que les données en rouge (communes actuelles). Les communes en vert renvoient systématiquement vers une commune actuelle ou une commune disparue. Les données en noir correspondent à des communes disparues (fusion ou fusion-association). De plus, pour complexifier le tout, Cassini a numéroté chaque commune (ou ancienne commune) par ordre alphabétique de l'ensemble des communes françaises métropolitaines, ce qui fait que Abjat-sur-Bandiat (code Insee 24001) est identifiée par Cassini sous le n° 56. Bon courage ! Père Igor (d) 15 octobre 2011 à 11:44 (CEST)

C'est effectivement une des grandes difficultés. Mais pas de découragement, j'y travaille! Vous ne pouvez pas imaginer ce que l'on peut faire avec ... Excel!! Demain et peut-être ce soir je publie la tyable de correspondance des 1979 communes actuelles commençant par A (sur les 3899 noms de communes commencant par A dans la base Cassini) avec leur code INSEE et bien sûr l'index Cassini et, tant qu'on y est, l'adresse de la page Cassini. Pour le nom dans Wikipédia, on verra plus tard.Roland45 (d)

Et voilà. Première livraison sur ces 1979 communes dont le nom commence par A. La table de correspondance est ici. On a maintenant de quoi travailler. Maintenant que l'on peut accéder à la page Cassini des communes, la question est : va-to pouvoir récupérer facilement les données de population ?Roland45 (d) 15 octobre 2011 à 21:13 (CEST)

De mon côté, à partir de l'url de la fiche Cassini, je récupère les données de population en PHP. J'arrête pour ce soir...--Juju2004 (d) 15 octobre 2011 à 21:45 (CEST)

Impeccable. J'étais en train de voir comment le faire en VBA. En fait on peut ouvrir une page html ds Excel et récupérer les données que l'on veut. Mais bon, ça va aussi pour moi.Roland45 (d) 15 octobre 2011 à 22:08 (CEST)

C'est bien que ça avance, mais il faut y aller pas à pas : ce n'est pas une course ! D'où vient le nom que tu fournis dans ton document ? INSEE où Cassini ? Regarde les questions que j'ai posées ci-dessus : il y a pas mal de points à éclaircir avant de se lancer tête baissée dans le codage. Père Igor a répondu à l'une d'elles : il n'y à qu'un seul numéro Cassini par code INSEE. Il reste les autres.--Juju2004 (d) 16 octobre 2011 à 10:42 (CEST)

Le nom de la commune qui figure dans le tableau Cassini A.xls est celui issu de la base Cassini, mais c'est aussi celui de l'INSEE, puisque c'est le nom officiel de la commune. Comme je l'ai dit plus haut, mais sans l'expliciter. La méthode que j'ai utilisée est la suivante : récupération du code source de la page A de Cassini puis traitement dans Word et Excel (une seule chaine de caractère de 364 pages, donc intraitable directement dans Excel!) où je n'ai retenu que les noms en rouge, avec leur index (de 3899 noms, on est tombé à 1979). Facile (à dire!). Ce qu'il reste à faire c'est à comparer avec la base INSEE 2010 pour voir si il en manque ou non. Quelques manipulations de cellules, lignes ou colonnes, cela ne va pas prendre une éternité. Cela m'étonnerait qu'il y ait des noms de communes INSEE qui ne soient pas dans Cassini, ou des orthographes différentes, sauf à ce que j'aie fait des erreurs de manip, ce qui peut aussi arriver. Donc effectivement pour être sûr de la base, il faut attendre cette comparaison. Pour info, je vais aussi fournir les noms dans Wikipédia.Roland45 (d) 16 octobre 2011 à 18:20 (CEST)

Merci pour cette réponse : le nom INSEE est donc celui qu'il fait prendre. Ton enthousiasme fait plaisir à voir, mais il ne faut pas placer la charrue avant les boeufs : le problème n'est pas d'arriver à faire les choses, mais de savoir quoi faire. Pour info, je réalise les trois opérations suivantes en PHP :

• à partir du numéro Cassini, récupérer les année/population ;
• construire la table de correspondance numéro INSEE-numéro Cassini ;
• récupérer les données du tableau BTX_CC_POP_2008.xls (après conversion CSV).

Il me semble donc que presque toutes les données utiles sont récupérables simplement. Le problème suivant est bien celui de la récupération des noms Wikipédia, mais il ne faut pas que le fasses : il faut que tu expliques comment on y arrive ! Je ne voudrais pas que tu prennes mal, mais quand on va présenter le projet pour validation (c'est un bot), on ne va pas dire : "on part des tableaux excel de Roland, et puis on fait ceci et cela". Il faut absolument montrer comment, depuis les données source, on construit les tables de données qu'on insèrera ensuite. On ne peut pas dire : "ça, c'est la cuisine de Roland ! on n'a jamais bien compris comment il avait fait, mais on lui a fait confiance." C'est une question de crédibilité du projet. Je répète : là où tu es plus utile, c'est pour dire ce qu'il faut faire (quel nom, comment tu l'associes à l'article WP, etc.) ; pour le faire, soit j'y arriverai, soit je trouverai quelqu'un pour m'aider. Je vais mettre à jour le tableau de la page de projet en conséquence : mettre uniquement les sources externes.--Juju2004 (d) 16 octobre 2011 à 20:15 (CEST)

Tout peut être expliqué et le sera. Mais je pense toutefois avoir une différence d'approche de fond avec toi. Pour moi seuls les données de Cassini doivent être récupérées à la volée sur le site de l'EHESS, toutes les autres doivent l'être non pas à partir de BTX_CC_POP_2008.xls, mais à partir d'un tableau dédié de celui-ci, mais aussi d'autres données, comme le nom dans wikipédia, les données 2007 issues d'un tableau précédent et toutes les données qui seront nécessaires pour le résumé introductif. Certes dans un premier temps, on peut se passer de certaines données, mais il faut l'avoir en perspective. Ainsi dans le résumé, on parle de rang national de la commune en 2008 ou en 1999. Ce rang se calcule à partir du tableau BTX_CC_POP_2008.xls. Ce serait bête d'y revenir plus tard. En tout cas une chose est sure, c'est que toutes les données dérivées doivent être expliquées.

On est d'accord sur ce dernier point. Mais je ne comprends pas exactement ce qui empêche de récupérer à la volée depuis BTX_CC_POP_2008.xls, Wikipédia, etc. Quel est ce tableau précédent dont sont issues les données 2007 ? Comment a-t-il été construit ? Pour le résumé introductif (prévu pour plus tard), le rang doit pouvoir se calculer à partir des données. Tu penses sans arrêt en tableau intermédiaire en raison de ton approche "Excel" du problème. Je maintiens qu'il existe des outils plus adaptés, dont le PHP.

Sur le fond, je suis en train de réfléchir à une solution de stockage temporaire dans une base de données locale qui pourra être exploitée pour la construction des tables de données. Il y a des obstacles, dont la validation du bot, ou l'autorisation de l'INSEE et de l'EHESS : on ne les franchira pas à coup de tableaux Excel.--Juju2004 (d) 17 octobre 2011 à 12:00 (CEST)

Le tableau précédent où apparaissent les données 2007 est tout simplement BTX_CC_POP_2007.xls qui a été publié l'an dernier, les données 2007 ne figurent en effet plus dans le tableau 2008. Je pensais qu'il avait disparu du net, mais je viens de le retrouver ici : http://megotclips.free.fr/Sociologie/GEOMATIQUE/BTX_CC_POP_2007/. Pour les années suivantes, on n'aura plus besoin que du tableau de l'année en cours puisque les Bdd de populations auront été crées dans WP (j'espère!).Roland45 (d) 17 octobre 2011 à 13:00 (CEST)

Okay, j'ai retrouvé les 2006 et 2007 sur le site de l'insee et je les mis sur la page principale. Si tu peux modifier les fichiers 2007 et 2008 pour des plus légers (avec seulement les recensements de ces années), ça serait un plus. Est-ce qu'il peut y en avoir d'autres ? (Y a-t-il eu des recensements entre 1999 et 2006 ?) Et est-ce que tu peux confirmer la coupure 1968 : avant 1968 sur Cassini, 1968 et après sur l'insee ?--Juju2004 (d) 17 octobre 2011 à 14:10 (CEST)

En réalité, dans mon script, je prenais les valeurs de Cassini de 1793 à 1999 non compris. J'utilisais l'Insee pour les années 1999 et suivantes (soit 1999, 2006, 2007 et 2008 aujourd'hui). Si Père Igor est d'accord, on peut partir sur ces bases. Roland45 (d) 17 octobre 2011 à 18:55 (CEST)

On va commencer par les méthodes pour récupérer les index de pages Cassini et les noms dans Wikipédia (qui pour moi ne doivent pas être reconstitués par le bot mais bien être récupérés et stockés dans le tableau dérivé).Roland45 (d) 16 octobre 2011 à 22:12 (CEST)

Méthode de récupération des index de pages Cassini

L'objectif est de récupérer les index de pages Cassini pour reconstituer l'url complet et constituer une table de correspondance qui servira ensuite à la saisie à la volée des données dans les pages de l'EHESS.

Il y a une page d'index par lettre. On va donc commencer à travailler lettre par lettre, mais pour une plus grande efficacité, il conviendra de travailler ensuite sur des blocs de pages.

Chaque page d'index recense des noms de communes avec les liens vers les pages correspondantes : en rouge les noms des communes actuelles, en noir les derniers noms connus de communes disparues et en vert des dénominations intermédiaires. Il convient donc de récupérer les noms en rouge.

Principe : Le code source est constitué d'une immense chaîne de caractères formée d'une suite de segments au format identique, commençant par "red", "green" ou "black" et séparés par ":". Il est donc clair qu'il va falloir couper cette chaîne au niveau des ":" puis trier pour ne récupérer que les segments commençant par "red" et enfin ne garder que les nom et index de chaque segment.

Méthode
Partie 1 :
Première difficulté : la chaîne de caractère ne tient pas dans une seule cellule Excel. Il faut donc passer par Word pour revenir ensuite dans Excel.

1/ Copier/coller dans Word la partie du code source où il y a les red, gren et black (pour la lettre A on obtient un texte continu de 364 pages!)
2/ Supprimer tous les segments de textes inutiles (avec la fonction REMPLACER) (on tombe à un doc d'une cinquantaine de pages)
3/ Ajouter des "retours chariots" en pied de chaque page (avant le dernier ":"), cela permettra de segmenter le texte en autant de lignes que de pages lors du passage dans Excel,
4/ Passer le tout dans Excel. On obtient un tableau à une colonne et une cinquantaine de lignes,
5/ Découper chaque cellule (avec "CONVERTIR") via le séparateur ":". On obtient un tableau à x colonnes et une cinquantaine de lignes, chaque cellule commençant par red, green ou black,

Partie 2
Deuxième difficulté : pour pouvoir récupérer l'index, on va devoir découper une nouvelle fois, mais pour cela il faut tout transformer le tableau en une seule colonne (commençant par red, green ou black). Deux options : soit faire un mini- programme, soit le faire manuellement. J'ai opté pour la deuxième avec tous les risques d'erreurs de manipulation que cela comporte

Partie 3
C'est la dernière ligne droit : on a un tableau à une colonne commençant par red, green ou black que l'on trie pour le garder que le red, puis que l'on redécoupe, pour ne garder que le nom, le code Insee et l'index.

Partie 4
On a récupéré les noms et index de Cassini, mais il faut maintenant comparer à la liste de noms de l'Insee 2010.

Pour cela on met dans Excel en vis-à-vis les deux colonnes (nom-code insee) issues respectivement de Cassini et de BTX_CC_POP_2008.xls. Un petit test élémentaire dans Excel permet de sortir les couples (nom-code insee) présents dans l'un et pas dans l'autre ou inversement. Il faut souligner ici un autre pb : pour les noms de communes commençant par un article (L'Abergement-Clémenciat ou Les Arcs par exemple), la base Cassini classe par rapport à la premières lettre du nom sans article (ici la lettre A) alors que dans la base Insee, ces noms, après tri alphabétique, sont classés à la lettre L. Il faut donc encore quelques manip pour retrouver ces noms dans la base Insee.

Résultats de la comparaison :
Le test a bien relevé des différences. Qui sont les suivantes :

• Des noms présents dans le tableau Insee et absents de la table issue de Cassini obtenue par la méthode ci-dessus :

73010	Albens	Figure bien dans Cassini, peut-être une erreur de manip
69004	Alix	id
26004	Alixan	id
27008	Alizay	id
64017	Alos-Sibas-Abense	id
38004	L'Albenc	id
60703	Aux Marais	Apparaît dans Cassini à la lettre M et non A
97102	Anse-Bertrand	Dép d'outre-mer, non pris en compte dans Cassini
97360	Apatou	id
97361	Awala-Yalimapo	id
97201	L'Ajoupa-Bouillon	id
97101	Les Abymes	id
97202	Les Anses-d'Arlet	id
97401	Les Avirons	id

• Un nom absent dans le tableau Insee et présent de la table issue de Cassini obtenue par la méthode ci-dessus : Amareins-Francheleins-Cesseins. En fait le code Insee 01165 renvoie à Francheleins

Voilà, il ne reste plus qu'à rectifier la table d'index (ce qui n'est pas encore fait), puis à recommencer pour les autres lettres (ou bien travailler par groupes de lettres).Roland45 (d) 17 octobre 2011 à 07:07 (CEST)

Conclusion

• Seule un traitement complet de toute la base permet de faire une vérification exhaustive;
• Il conviendra probablement que le bot traite différemment les départements d'outre-mer puisqu'ils ne sont pas présents dans la base Cassini (ce que l'on peut vérifier ici) (et pour cause puisque la départementalisation des DOM date de 1946).Roland45 (d) 17 octobre 2011 à 07:57 (CEST)

Ok Roland, tu sais le faire, mais je te répète que ce n'est pas la bonne méthode. J'ai un bout de code de 30 lignes qui fait ça sans aucune intervention humaine, aucun copier-coller, etc. Quand je te demande comment tu fais, ce n'est pas comment tu fais en Excel, c'est la logique de ta démarche. Parce que cette logique va pouvoir se traduire en PHP très facilement ; parce qu'on va voir s'il y a des optimisations possibles ; parce qu'on va voir s'il y a des failles ou non. C'est là que tu es utile, pas avec Excel (du moins pas sur ce coup là). Désolé d'avoir à le dire si brutalement, mais si on veut aller au bout du début, il faut fonctionner autrement que ce que tu proposes.--Juju2004 (d) 17 octobre 2011 à 12:11 (CEST)

Bon, je pensais que tu avais besoin de la table d'adressage des pages Cassini. Si tu veux la récupérer tout seul, pas de pb. Mais tout était déjà dit plus haut : il suffit de récupérer les noms en rouge sur la page d'index par lettres de Cassini et point barre, je me doute qu'en balayant la chaîne de caractère du code tu peux le récupérer. Pour ce qui est de la transparence, je peux te renvoyer la balle, car avec ma méthode tout le monde peut vérifier, car Excel c'est en clair, tandis que le bot lui n'est pas en clair (soit dit en passant je n'ai pas vu ton bout de code de 30 lignes pour récupérer la table d'index). Donc je considère que tu as tout ce qu'il faut pour récupérer toutes les données Cassini.Roland45 (d) 17 octobre 2011 à 12:40 (CEST)

L'ensemble du code PHP du bot sera publié : c'est bien le seul moyen d'obtenir que ce bot soit autorisé. Je ne publie pas pour l'instant le bout de code 30 lignes parce que si je commence, ça va être du PHP (probablement perfectible) aux quatre coins de la page pour un bénéfice nul. Pour l'instant, j'essaie de poser les jalons : quelles étapes sont à réaliser ? comment (de manière générale) ? à partir de quelles données ? C'est la première étape de la transparence. Et je ne peux pas faire ça parce que je n'ai pas les connaissances du domaine (cdf) : j'ai donc besoin de tes éclairages (et de ceux des autres bonnes volontés). Une fois que tout sera prêt, il n'y aura qu'à assembler les parties, faire valider l'engin et démarrer le travail.--Juju2004 (d) 17 octobre 2011 à 14:18 (CEST)

Méthode de récupération des noms de communes dans Wikipédia

Pour rappel les noms de communes qui sont en doublon avec un autre nom commun ou propre sont en, général, suivis dans Wikipédia du nom du département d'appartenance entre parenthèses. C'est ce "en général" qui pose problème. En effet, même si les cas sont extrèmement rares, l'entrée est quelquefois le nom de la commune et non la page d'homonymie.

Méthode exacte, mais aussi la plus longue

1/ Récupérer le code de chaque liste figurant dans Listes des communes de France,
2/ Pour chaque code, récupérer le texte se trouvant dans le tableau de la section "Liste" en commençant par le 1er "| align="left" jusqu'au dernier. Prenons l'exemple de l'Ain, on obtient un tableau à une colonne et 838 lignes,
3/ Tri sur la 1ère colonne et suppression des " |-". Le tableau n'a plus que 419 lignes,
4/ Conversion de la colonne A sur le séparateur "[", on obtient un tableau à 3 colonnes,
5/ Conversion de la colonne B du nouveau tableau sur le séparateur "]", on obtient un tableau en 3 colonnes dont la 2ème contient le nom de Wikipédia,
6/ Conversion de la colonne C sur le séparateur "|" et le code INSEE est récupéré en colonne D,
7/ On efface toutes les colonnes qui ne servent à rien, il nous reste les deux données qui nous intéressent : le code INSEE et le nom wikipédia. (temps des 7 premières manip : 3 min max),
8/ Recommencer la manip sur les 100 codes de département,
9/ Agréger toutes les feuilles de calcul et trier selon le code INSEE,
On obtient un tableau à 2 colonnes (INSEE-nom wikipédia) et 36800 et quelques lignes.

Un gain de temps peut être obtenu en agrégeant dès le début les codes, puis en convertissant, on gagne 99 fois les manip 3 à 7 mais il faut aussi gérer le fait que l'on obtient un tableau de 72000 lignes supérieur aux 64000 lignes d'Excel, mais ce n'est pas un pb.

Je vois en gros la démarche. Ce que j'attendais, c'est simplement ceci :

• récupération des listes de communes par département à partir de la page "Listes des communes de France" ;
• récupération des codes INSEE et noms WP de communes à partir des pages "Liste des commues de XXX".

A partir de là, la question est : d'où viennent ces listes et qu'est-ce qui garantit qu'elles sont à jour ?--Juju2004 (d) 17 octobre 2011 à 12:16 (CEST)

Sur la qualité des listes, je pourrais te dire que le projet "Communes de France" est suffisamment structuré pour ne pas avoir laissé passé la moindre erreur, mais comme nul n'est infaillible, la réponse est plutôt : il suffit de comparer avec la liste du tableau INSEE ... l'ennui c'est que pour comparer il faut avoir ladite-liste!! Donc en l'état, on ne sait effectivement pas si cette liste est conforme à la liste Insee.Roland45 (d) 17 octobre 2011 à 12:47 (CEST)

Il faut être pragmatique en la matière. Il n'existe aucune liste et aucune catégorie qui soit fiable à 100 %. Entre les fusions et scissions de communes les listes et catégories évoluent avec les risques d'oublis et d'erreur que cela implique. C'est pourquoi, je propose d'utiliser quand même ces listes et éventuellement catégories mais en prévoyant, si on utilise le bot, un script de traitement d'erreur assez simple qui dans un premier temps créé par exemple les modèles de données pour les articles de communes dont le nom de l'article correspond scrupuleusement au nom de la commune, puis dans un second temps, on consultera le rapport du bot où il aura dressé une liste de toutes les pages de communes qu'il n'a pas pu traiter en raison d'une erreur dans le nom des articles concerné. Enfin bref, on pourrait imaginer un système comme ça. A mon avis ce sera plus raisonnable et la charge de travail s'en trouvera réduite. amicalement--Wikialine (d) 18 octobre 2011 à 02:36 (CEST)

Finalement, je me range à la méthodo proposée par juju ci-dessous sans faire appel à une liste.Roland45 (d) 18 octobre 2011 à 07:41 (CEST)

Méthode moins exacte, mais la plus rapide

1/ Partir du fichier BTX_CC_POP_2008.xls et ne garder que le code INSEE et le nom de la commune,
2/ Eventuellement ne travailler que sur la lettre A ('mais on peut travailler sur tout le fichier),
3/ Trier sur le nom de la commune,
4/ Tester les noms en doublon (sur Excel, c'est élémentaire),
5/ Récupérer le nom du département en croisant (fonction RECHERCHEV) le code du département avec une table des départements,
6/ Concaténer nom commune et nom département et parenthèses

On a ainsi géré les doublons de noms de communes entre eux, mais on doit aussi gérer les doublons avec d'autres noms propres (Allier) ou avec d'autres noms communs (Autruche). Là c'est plus difficile. Pour ma part, féru de mots croisés, je dispose de la base des noms communs du Petit Larousse. J'ai donc croisé les deux bases et regardé les doublons (pour la lettre A).

Là se pose une difficulté, un doublon ne conduit pas spécifiquement à l'ajout du nom du département au nom de la commune, car le principe de la moindre surprise prévalant, quelquefois, le nom de la commune est la première entrée!! Comment gérer donc ? En vérifiant à la main.

C'est ce que j'ai fait pour la lettre A pour aller vite, mais ce n'est guère envisageable sur l'ensemble du fichier. La seule méthode valable est bien la première.

Je suis beaucoup plus intéressé par cette méthode (sauf éclaircissements sur la liste ci-dessus), d'autant plus qu'on peut faire un plus d'efforts pour trouver les noms (différents essais sont autorisés). On doit pouvoir régler 99% des cas en testant la présence d'une ou plusieurs catégories, en vérifiant la présence de mot-clés, etc. Il faudrait examiner les étapes à mettre en oeuvre pour que cette méthode fonctionne le mieux possible.--Juju2004 (d) 17 octobre 2011 à 12:22 (CEST)

Je doute que tu puisses reconstituer une liste complète des noms WP par bot. Au mieux tu peux traiter les doublons d'homonymie de noms de communes et effectivement donner leurs noms WP (en ajoutant le nom de département), mais tu auras assurément du mal à trouver les homonylies avec les noms communs ou propres qui ne soient pas un nom de commune. La meilleure méthode est bien, me semble-t-il, la précédente.Roland45 (d) 17 octobre 2011 à 12:52 (CEST)

En fait, la méthode peut-être dynamique, en interrogeant WP en direct :

1. test de l'existence de la page "<nom de commune> (<nom de département>)" ;
2. test de l'existence de la page "<nom de commune> (commune)" (est-ce que ça existe ?) ;
3. test de l'existence de la page "<nom de commune>".

Le premier essai qui marche est considéré comme le nom WP de la commune. Est-ce que tu vois des cas qui sortent de là ?--Juju2004 (d) 17 octobre 2011 à 14:25 (CEST)

Cette méthode me semble effectivement couvrir tous les cas de figure, à condition d'une part de bien entrer par le nom figurant dans la base de l'Insee (LIBGEO) et d'autre part de ne tester que le code de département concerné (2 premiers chiffres du code insee). Les seuls cas qui pourraient ne pas entrer dans la méthodo seraient de nouveaux renommages qui n'auraient pas été pris en compte dans WP, mais cela paraît exclus.Roland45 (d) 18 octobre 2011 à 07:37 (CEST)

Bonjour à tous, je débarque un peu comme un cheveu sur la soupe, wikislow oblige ! Félicitations en tout cas pour cette initiative ! Petite remarque (qui a peut-être déjà été abordée ailleurs, mes excuses ci c'est le cas) : comment gérer les écarts entre le nom officiel du COG et certains titres d'articles de Wikipedia qui ne suivent pas le COG ? — Droop ^[blabla] 30 octobre 2011 à 09:02 (CET)

Salut. Jusqu'à il y a quelques minutes, je pensais que la méthode ci-dessus permettait de trouver toute les communes exhaustivement. Mais je viens de trouver : Lazer dans les Hautes-Alpes qui ne respecte pas les règles ci-dessus puisque le qualifiant est "commune française". Ja vais balayer tous les noms pour voir si il y a d'autres exceptions. Cela doit quand même être à la marge.Roland45 (d) 30 octobre 2011 à 09:41 (CET)

Autre anomalie, plus difficile à détecter : la commune de Saint-Champ, dans l'Ain, est dénomnée Saint-Champ-Chatonod dans WP. Je crois que l'on va devoir tout vérifier!!!Roland45 (d) 30 octobre 2011 à 10:07 (CET)

Encore plus problématique : Bors (16053) et Bors (16052) dans deux cantons limitrophes du même département!!!Roland45 (d) 30 octobre 2011 à 10:26 (CET)

Pas de panique ! L'idée est que le bot va parcourir les fichiers sources et essayer d'y faire correspondre des articles WP. En cas d'échec, il est possible de procéder de la manière suivante :

• création de la page de données avec un nom standardisé (au pire, l'identifiant INSEE entre parenthèses pour éviter toute homonymie) ;
• le nom de la commune et son COG seront écrits dans un fichier log contenant tous les échecs.

Il suffira par la suite de parcourir ce log et de renommer manuellement la page de données pour qu'elle corresponde au nom WP, ou éventuellement de modifier le nom WP s'il n'est pas bon. Cela n'empêche pas qu'il est intéressant d'avoir une idée des exceptions qui peuvent exister.--Juju2004 (d) 31 octobre 2011 à 09:34 (CET)

Bonjour. Il me semble primordial que cette liste d'exceptions soit connue. Aussi je crée la page ad-hoc. Cordialement. AntonyB (d) 31 octobre 2011 à 22:27 (CET)

Je viens de la compléter pour les 3 662 communes des départements 01 à 10, en prenant en compte les évolutions de nom depuis l'édition du COG (cas des cinq communes qui ont changé de nom le 22 mars 2011 : Croix-Fonsomme, Fonsomme, Saint-Paul-de-Vence, Saint-Just-d'Ardèche, Noé-les-Mallets). Cordialement. AntonyB (d) 31 octobre 2011 à 23:31 (CET)

Mission 2 du bot - Mise à jour des modèles données

Telle que tu décris la construction de la Bdd dans la page projet, j'ai l'impression que tu reconstruis la page de la Bdd de chaque commune chaque année (mais je me trompe peut-être). Pour ma part je pensais que tu construisais la Bdd une fois puis que tu l'actualisais l'année suivante en ne rajoutant que les données à l'année en cours. Mais il est vrai que l'on peut reconstruire à chaque fois, cela permettra d'éliminer les données parasites (c'est surtyout valable pour la pyramide des âges qui sont caduques l'année suivante).Roland45 (d) 17 octobre 2011 à 19:20 (CEST)

En fait, je n'ai pas d'avis tranché sur la question : il y a du pour et du contre. En particulier ces "données parasites", qui peuvent être du plus ou du moins. Du moins, c'est évident : introduction d'erreurs par exemple. Du plus aussi : correction d'erreurs à partir d'une source plus pertinente. On pourrait développer la précaution prise avec {{Données mises à jour manuellement}} en ajoutant un autre modèle :

• {{Données mises à jour manuellement}} : le bot passe son chemin ;
• {{Données corrigées}} : le bot ne change rien à ce qui existe, mais ajoute éventuellement quelque chose ;
• cas général : on écrase simplement les données avec la nouvelle version (le plus simple).

Qu'en penses-tu ?--Juju2004 (d) 18 octobre 2011 à 09:22 (CEST)

J'étais parti sur l'idée d'ajouter des données sur des bases existantes, mais je crois que l'option de reconstruire complètement chaque article de Bdd chaque année me parait plus propre. Car avant de lancer le bot, on teste sur quelques communes et si par exemple l'adresse d'une source ancienne à changé, cela permet de mettre la bonne.Roland45 (d) 18 octobre 2011 à 13:36 (CEST)

Que faire en cas d'apparition de commune ?

Cette question concerne le futur : que faire si une ligne contient un code officiel géographique inconnu ? On peut l'interpréter a priori comme une scission. Si c'est le cas, il est bien évidemment impossible pour le bot : 1. de deviner d'avec quelle commune il y a eu scission ; 2. de répartir correctement les populations passées entre ces deux communes. Je propose la solution suivante :

1. le bot signale la nouvelle commune ;
2. autant que possible, les données des deux communes impliquées dans la scisssion sont mises à jour manuellement ;
3. on insère manuellement le modèle {{Données corrigées}} qui prévient le bot de se contenter d'ajouter des données, mais de ne jamais modifier celles existantes.

Cela convient-il, ou bien y a-t-il d'autres solutions ?--Juju2004 (d) 21 octobre 2011 à 10:41 (CEST)

Bonjour. Pour ton information : comme je l'ai déjà indiqué plusieurs fois, les communes qui apparaissent ou qui disparaissent sont des faits très rares, de l'ordre d'une occurrence par an. Tu trouveras la liste ici. Crdialement. AntonyB (d) 21 octobre 2011 à 11:41 (CEST)

La quasi-totalité des fusions ou scissions de communes aboutit à utiliser l'un des codes officiels géographiques (COG) des communes fusionnées, ou de retrouver l'ancien COG d'une commune qui a défusionné. Dans la liste signalée par AntonyB, aucun nouveau COG. Il pourrait se faire cependant qu'effectivement une partie substantielle de commune décide de prendre son autonomie et génère un nouveau COG. Père Igor (d) 22 octobre 2011 à 11:23 (CEST)

Débats sur les sources

Question légale

discussion temporairement close (n'hésitez pas à la rouvrir)

Je me pose une question par rapport à ce projet. Est-ce que l'utilisation massive des données INSEE et autres est légale ? Je suppose que oui, mais je pense qu'il faudrait s'en assurer auprès de spécialistes. Projet:Droit ?--Juju2004 (d) 1 octobre 2011 à 10:43 (CEST)

ça fait des années qu'au sein du projet communes de France, on ajoute les données de l'Insee et de Cassini dans nos articles de communes de France (+ de 36 600 articles). Il faudrait demander aux plus anciens utilisateurs si la question juridique a été soulevée. --Wikialine (d) 2 octobre 2011 à 15:28 (CEST)

Je parle bien de l'usage massif et automatisé des données. J'imagine que l'usage ponctuel est autorisé, mais de là à récupérer l'intégralité de ces données, je suis plus circonspect, même si c'est pour la bonne cause ().--Juju2004 (d) 2 octobre 2011 à 21:21 (CEST)

Question posée sur Wikipédia:Legifer. Espérons que ça soit autorisé...--Juju2004 (d) 4 octobre 2011 à 18:18 (CEST)

Mauvaise nouvelle : sans autorisation préalable, ce serait illégal. Voir Wikipédia:Legifer/octobre_2011#Utilisation_massive_et_automatis.C3.A9e_de_donn.C3.A9es_INSEE. Il faudra donc essayer d'obtenir l'autorisation des organismes qui possèdent les droits sur les données (INSEE à coup sûr, et Cassini s'ils ne bénéficient pas déjà eux-mêmes d'une autorisation). L'avantage est qu'on pourra déjà présenter des modèles avec les sources qui apparaissent.--Juju2004 (d) 4 octobre 2011 à 21:24 (CEST)

Tout cela n'est pas évident. Le plus simple serait de demander directement à l'Insee. Ou alors de jouer sur la définition floue du terme "substantielle". Par rapport à la quantité importante d'informations fournies par l'Insee, en définitive ne prélever "que" le nombre de population pour chaque commune + éventuellement les données de pyramide des ages pour seulement 2 dates (comme cela est fait généralement sur nos articles), ça reste minime si on compare à la quantité de données émises au totale par l'Insee pour chaque collectivités territoriales. Par ailleurs, il existe des précédents sur Internet qui démontrent que la prise de certaines informations sur le site de l'Insee ne pose pas de problèmes. Lorsque je travaille sur les articles de communes, très souvent, je consulte le site http://www.linternaute.com/ville/ville/demographie/1162/chambery.shtml . Ce site est un poids lourd sur Internet, si eux peuvent le faire a priori WP le peut également. En toute objectivité en observant le net, on peut se faire une idée précise de ce que l'on peut ou ne peut pas faire. En l'occurrence, la récupération des données démographiques visées ici ne devraient pas poser trop de problème, mais encore une fois on peut toujours consulter les responsables du site de l'Insee...amicalement--Wikialine (d) 4 octobre 2011 à 23:43 (CEST)

Il est à mon avis risqué de se fonder sur ce qui se passe sur le net pour deux raisons : 1. les sites dont tu parles ont peut-être obtenu une autorisation de l'INSEE ; 2. WP est un site collaboratif, et même si l'INSEE n'intervient pas, le risque juridique peut être soulevé par la communauté pour mettre fin au projet. Je vais réinterroger WP:Legifer par rapport au fait que les données de population sont peu de choses par rapport à l'ensemble des données (s'il ne s'agit que de deux dates, je suis d'accord que c'est non substantiel, mais le projet est plus vaste, non ?). Si la réponse est négative, il faudra faire une demande officielle à l'INSEE.--Juju2004 (d) 5 octobre 2011 à 08:45 (CEST)

Sur le site de l'Insee sur la page suivante http://www.insee.fr/fr/bases-de-donnees/default.asp?page=fichiers_detail/conditions_fic_detail.htm il est est dit la chose suivante : « Conditions d'utilisation des fichiers détail Les fichiers et leur documentation sont la propriété de l'Insee. Ils peuvent être téléchargés gratuitement et les données contenues dans les fichiers peuvent être réutilisées, y compris à des fins commerciales, sans licence et sans versement de redevance. De convention expresse, dans tous les cas, aucune garantie tacite ou implicite n'est accordée par l'Insee, que ce soit au titre de préjudice direct ou indirect, commercial ou financier ou pour toute autre cause. La mise en œuvre des fichiers est faite sous l'entière responsabilité de l'utilisateur, en particulier quant aux résultats obtenus à partir de ceux-ci. L'Insee n'assure aucun service de quelque nature qu'il soit, notamment de conseil, tant sur la documentation fournie que sur les fichiers eux-mêmes. Les fichiers sont généralement proposés au format dBase et au format Beyond 20/20®. »

Il faudrait creuser un peu, je n'ai pas eu le temps de voir de plus près ce que cela recouvre. Affaire à suivre... amicalement--Wikialine (d) 5 octobre 2011 à 19:28 (CEST)

En tout cas, ça sent très bon pour l'INSEE ! Je vais aller voir. Il faudrait également se renseigner pour les autres sites que tu veux utiliser. Est-ce que tu pourrais mettre dans Projet:Communes de France/Mise à jour automatique des données démographiques les sources envisagées, les fichers concernés (avec leur adresse, format de données) ? Ça permettrait de se faire une idée plus précise. Je vais également essayer de compléter cette page avec des indications sur l'architecture du système (point de vue technique).--Juju2004 (d) 5 octobre 2011 à 20:29 (CEST)

J'ai commencé brièvement à remettre à jour la page Projet:Communes de France/Mise à jour automatique des données démographiques avec les nouvelles modifications discutés ici afin que l'on ait une vision globale du système. N'hésite pas à y apporter des précisions. Je vais commencer à évoquer les sources effectivement leur recensement est important. amicalement--Wikialine (d) 5 octobre 2011 à 21:14 (CEST)

Le texte que tu as exhumé ne s'applique pas aux bases qu'on veut utiliser ! Heureusement, j'ai trouvé ceci [3]. J'ai redemandé un avis sur WP:Legifer, et la suggestion de Biem me parait pertinent : construire quelque chose qui marche (ce qu'on est en train de faire), puis n'importer dans un premier temps que les données pour les articles qui commencent par une lettre ("S" est à mon avis assez fréquent). Cela ne demande pas d'autorisation préalable. Ce sera un genre de preuve de faisabilité par rapport à WP et une vitrine pour présenter à l'INSEE quelque chose de clean et qui leur donne envie de nous donner l'autorisation de procéder à une importation intégrale des données.--Juju2004 (d) 7 octobre 2011 à 16:50 (CEST)

On trouve également cette mention de réutilisation gratuite y compris à des fins commerciales sur la page des mentions légales ici.Roland45 (d) 14 octobre 2011 à 06:43 (CEST)

Comme dit dans l'analyse de Biem sur WP:Legifer, le "sauf mention contraire" est une sorte de joker auquel il faut prendre garde. Donc, dans un premier temps, on va travailler sur un sous-ensemble. Je pense qu'on peut clore pour l'instant cette question, dans la mesure où c'est également un choix raisonnable dans la conduite du projet : ne pas lancer tout un bot sur l'ensemble des communes, c'est se donner les moyens d'examiner les résultats produits à la loupe et d'améliorer les choses, ainsi que de faire accepter ce qui est fait à la communauté (il faudra de toute manière une autorisation du bot avant de commencer, mais c'est autre chose). Dans ce cadre, il faudra même se limiter dans un premier temps à un sous-sous-ensemble.--Juju2004 (d) 14 octobre 2011 à 10:24 (CEST)

 

Chiffres Insee erronés dans certains cas de fusions de communes

Je n'interviens ici que pour rappeler que dans les cas de fusions de communes, les chiffres de l'Insee sont parfois sujets à caution et doivent être vérifiés « humainement ».

Autant EHESS/Cassini indique le recensement réel propre à chaque année (valable jusqu'en 1990, moins vrai pour 1999), autant l'Insee fournit des données « à périmètre égal ». Donc celles qui concernent une période antérieure à une fusion, sont erronées.

Exemple pour Mauléon (Deux-Sèvres), le chiffre 1968 est presque 3 fois trop fort car il intègre les communes de La Chapelle-Largeau, Loublande, Moulins, Rorthais, Saint-Aubin-de-Baubigné et Le Temple, qui n'ont fusionné qu'à partir de 1973. Par contre, de 1975 à 1990, les chiffres Insee sont minorés d'environ 1 200 habitants car ils oublient de compter la commune de Saint-Amand-sur-Sèvre qui était en fusion-association avec Mauléon à partir de 1973 mais qui a repris son indépendance en 1992. Voir Mauléon (Deux-Sèvres)#Démographie et Saint-Amand-sur-Sèvre#Démographie pour voir comment j'ai résolu, manuellement, le problème.

Un autre cas, extrême, concerne Argenton-les-Vallées, commune créée en 2006 par la fusion de trois autres. L'Insee considère un historique réel depuis 1968 correspondant au code Insee d'Argenton-Château qui a été conservé sur la nouvelle commune.

Dans un souci de vérité, il serait bon, de lister les communes qui ont subi des modifications de limites après 1962, afin de les exclure d'une programmation automatique. Père Igor (d) 8 octobre 2011 à 17:53 (CEST)

Merci pour l'information. Le bot, qui est le deuxième étage de la fusée, reste à mettre en place : il faut voir comment on va prendre ces cas en compte, mais il est vrai qu'il serait intéressant de récupérer la liste des communes concernées.--Juju2004 (d) 8 octobre 2011 à 19:41 (CEST)

Maintenant qu'on est en plein dans la conception du bot, je reviens sur ce point. Si je comprends bien ce que tu écris, et que j'essaie de le traduire pour une exploitation informatique, j'ai ceci :

• chaque ligne des fichiers INSEE correspond à une commune existante à la date présente ; les communes fusionnées disparaissent, sauf le "vainqueur" ;
• la population fournie à chaque recensement est la somme des populations des communes fusionnées à la date présente (peu importe l'historique) ;
• au contraire, Cassini conserve les communes "perdantes" (ex. La Chapelle-Largeau) avec des recensements vides à partir du moment de la fusion.

J'en déduis (si ces points sont validés) :

1. il y a plus de communes dans Cassini que sur le fichier de l'INSEE : on ne peut donc pas se contenter de reprendre les noms dans le fichier INSEE, il existe des noms de communes hors fichier INSEE et qui nous intéressent ;
2. les données Cassini sont plus fiables que les données INSEE (jusqu'où ?).

Est-ce juste ?--Juju2004 (d) 18 octobre 2011 à 09:41 (CEST)

Apparemment, Cassini a conservé 41 475 communes comme le prouve la dernière par ordre alphabétique. Pour la fiabilité des données Cassini, voir mes divagations d'hier. Père Igor (d) 18 octobre 2011 à 12:50 (CEST)

Une source unique pour évolution population et pyramide des âges

Je viens de remplacer les deux sources citées par celle que j'utilise pour le script Excel. Celle-ci présente l'avantage de fournir en un seul tableau les populations par communes pour chaque commune de 1968 à 2008 mais également par tranches d'âges pour la dernière année de recensement (2008). Chaque année le fichier a le même nom, seul l'année change.

Sources des données pour les années 1968 à la dernière année de recensement

Données à récupérer	Nom du fichier	Type de fichier	Contenu	Organisme source	Lien
Années/Population/pyramides des âges de 1962 à 2008 (métropole + départements OM)	BTX_CC_POP_2008.xls	Excel	Évolution et structure de la population pour les recensements de 1962 à 2008	INSEE	[4]

Communes d'Alsace-Lorraine, de Savoie ou du Comté de Nice

Chaque fiche Cassini indique toujours les mêmes dates de recensements, quelle que soit la commune concernée. Or, les communes situées anciennement en Alsace-Lorraine, dans le duché de Savoie ou le comté de Nice ont un historique différent. Les dates de recensements de Strasbourg, Annecy ou Nice par exemple doivent être corrigées en fonction des avertissements répétés sur chaque fiche Cassini, à savoir : « Pour l'Alsace-Lorraine, les recensements de la période 1870-1919 ont eu lieu aux années 0 et 5 sauf 1871, et 1915 qui n'a pas été réalisé. Pour Nice et la Savoie, les recensements de la période 1814-1860 ont eu lieu en 1815, 1822, 1838, 1848 et 1858 », ce qui explique les mentions « abs. » face à certaines dates. Départements touchés : le Bas-Rhin (67), le Haut-Rhin (68), la Moselle (57), les Alpes-Maritimes (06), la Savoie (73) et la Haute-Savoie (74). Père Igor (d) 17 octobre 2011 à 17:23 (CEST)

Effectivement le site de l'EHESS doit utiliser une matrice commune à toutes les communes. Dans le traitement de la base Cassini, il conviendra de modifier les dates pour les départements en question, à l'instar de ce qui est fait dans le script Excel (voir les formules dans la colonne T, ligne 50 à 86).Roland45 (d) 17 octobre 2011 à 19:04 (CEST)

A nouveau, je suis un peu à la traîne pour comprendre ce que signifie, par ex., les "années 0 et 5" (de quoi ?). Je veux bien quelques compléments d'explication, mais (principalement) ma question est la suivante : les années inscrites dans le tableau sont-elles correctes ? Parce que l'idée est de récupérer, pour chaque fiche Cassini, les années et les populations fournies, pas de se fonder sur l'idée que les années sont toujours les mêmes.--Juju2004 (d) 18 octobre 2011 à 09:46 (CEST)

Pour les 6 départements que j'ai cités plus haut, certaines dates de recensements sont obligatoirement fausses. Le chiffre de population est bon, mais il faut adapter la date. Si tu regardes la fiche Cassini de Strasbourg, les dates de recensements indiquées sont 1872, 1881, 1886, 1891, 1896, 1901, 1906, 1911, qu'il faut donc adapter en 1871, 1885, 1890, 1895, 1900, 1905, 1910. Pour Annecy, les dates indiquées 1821, 1836, 1846, 1856 sont à traduire en 1822, 1838, 1848, 1858. Père Igor (d) 18 octobre 2011 à 12:01 (CEST)

C'est clair maintenant : je fais passer l'information sur la "page d'en face". S'il y a lieu, n'hésite pas à corriger.--Juju2004 (d) 18 octobre 2011 à 13:39 (CEST)

Attention, ce n'est pas le département des Alpes-Maritimes qui doit être corrigé au niveau des dates de recensement, mais uniquement les communes de l'arrondisement de Nice et avec les années 1815, 1822, 1838, 1848 et 1858 et pas uniquement 1822, 1838, 1848 et 1858. Petit point d'histoire. Après la création du département des Alpes-Maritimes en 1793, le comté de Nice retourne en 1814 au royaume de Piémont-Sardaigne et Monaco recouvre son indépendance et passe sous protectorat sarde. Le second département des Alpes-Maritimes est créé en 1860. Ainsi les corrections doivent être affectées pour les communes ddu Comté de Nice qui correspond sensiblement à l'arrondissemnt actuel de Nice (d'après ce qui est dit dans l'article sur le comté de Nice), mais je n'ai pas la liste exacte des communes concernées (donc prendre l'arrondissement).Roland45 (d) 18 octobre 2011 à 19:56 (CEST)

Bien vu. Un moyen pour repérer les communes concernées consiste à identifier celles qui ont la mention « abs. » en 1831, 1841 et 1851, alors que 1821, 1836, 1846 indiquent bien un chiffre de population. Quant au recensement de 1815, Cassini a apparemment fait l'impasse dessus car les recensements pour les autres communes françaises sont passés directement de 1806 à 1821. Père Igor (d) 18 octobre 2011 à 21:39 (CEST)

Ok. Dès que j'ai le temps, je transpose ces infos en page d'en face.--Juju2004 (d) 19 octobre 2011 à 09:46 (CEST)

Vu, mais tu peux peut-être scinder ce cas en deux : toutes les communes sont concernées dans les départements 73 et 74 ; les communes du département 06 ne sont pas toutes au même régime. Père Igor (d) 19 octobre 2011 à 12:22 (CEST)

Corrections de certaines valeurs et choix INSEE/Cassini

Au cas où ça pourrait intéresser, j'ai fini par retrouver la trace du recensement 1962 (ou 1961 pour les DOM) sur le site de l'Insee. Ça se passe ici, mais c'est une source que je n'utilise pas. Maintenant, ce n'est pas à moi à donner un feu vert ou rouge. Je constate simplement que pour la majorité des communes, Cassini est la seule base valable jusqu'en 1954 inclus ; que dès qu'il y a fusion ou défusion de communes après 1954, il y a un problème d'historique à l'Insee (problème que ne connait pas Cassini) ; que les chiffres de 1999 de l'Insee et de Cassini présentent souvent quelques habitant de différence et que, personnellement, je privilégie l'Insee à 99,99 % (en dehors des cas de fusion ou défusion de communes) ; que Cassini affiche pour la date 2006 le recensement réel de 2004, 2005 ou 2006 des communes de moins de 10 000 habitants ; que Cassini n'affiche rien pour les recensements de 2007 ou suivants ; que les chiffres de 2006, 2007 et 2008 sont accessibles sur l'Insee (mais qu'ils peuvent être faux en cas rarissimes de fusion ou défusion de communes postérieure à ces dates) ; que les dates réelles de recensements du XXI^e siècle des petites communes (tous les cinq ans) sont fournies par l'Insee ; que ce même site indique les communes de plus de 10 000 habitants faisant l'objet d'un recensement partiel chaque année. Père Igor (d) 17 octobre 2011 à 19:38 (CEST)

On n'est pas encore sur la question du feu vert ou rouge : il faudra représenter ce projet devant le projet CDF pour commentaires, puis faire valider le bot. Donc on peut essayer de faire au mieux, et puis on verra. Si je lis bien, tu proposes Cassini jusqu'en 1999 inclus, INSEE au-delà, car :

• l'INSEE gère mal (par rapport à notre objectif, évidemment) les fusions et défusions ;
• Cassini gère mal les recensements réels 2004, 2005, 2006 (tous attribués à 2006).

Cassini jusqu'à 1999 exclus, càd jusqu'à 1990 inclus, INSEE pour les années 1999 et suivantes.Roland45 (d) 18 octobre 2011 à 13:42 (CEST)

 Fait. (Ce qui signifie : mise à jour de la "page d'en face".) J'ai mis le fichier fourni par Père Igor pour les DOM. N'hésitez pas à corriger si nécessaire.--Juju2004 (d) 18 octobre 2011 à 17:27 (CEST)

Voici une autre batterie (il y en a une plus haut) de questions :

• est-ce que l'INSEE fait mieux sur 2004, 2005, 2006 ? Si oui, ou prendre les données ?

C'est l'INSEE la référence.Roland45 (d) 18 octobre 2011 à 14:01 (CEST)

C'est bien entendu l'Insee la référence mais Cassini a enregistré sous la seule année 2006 les recensements Insee 2004, 2005 et 2006 des petites communes (moins de 10 000 habitants). Père Igor (d) 18 octobre 2011 à 17:14 (CEST)

"Est-ce que l'INSEE fait mieux ?" : je parlais en terme de publication. La question est donc : est-ce que, à partir de fichiers INSEE, on peut réussir à récupérer les recensements de 2004 et 2005 ? J'ouvre une nouvelle section ci-dessous sur la question.--Juju2004 (d) 18 octobre 2011 à 17:37 (CEST)

Non et on n'en a pas besoin. En effet suite à une discussion sur le projet "Communes de France", il a été décidé d'afficher dans le graphique : l'année 1999, l'année 2006, puis le premier recenseemnt réel postérieur à 2006 puis le suivant (dont 5 ans après). On n'a donc pas besoin de 2004 ni de 2005.Roland45 (d) 18 octobre 2011 à 18:49 (CEST)

Tu n'en as pas besoin car en en tant que programmeur informatique, tu dois t'éclater avec tes programmes et comme tu es dans l'incapacité de récupérer la totalité des recensements, tu décides d'éliminer le problème. Il y a aussi des utilisateurs (moi par exemple) qui s'éclatent en travaillant article après article sans aucun bot. Pour mémoire, je suis un des quelques participants à mettre à jour chaque année depuis trois ans les populations de communes, cantons, arrondissements, intercommunalités, départements, portails (voir 2009, 2010 et 2011). Père Igor (d) 18 octobre 2011 à 22:15 (CEST)

C'est me faire un trop grand honneur. Juju et wikialine sont des programmeurs. Moi, je ne suis qu'un bidouilleur, un amateur éclairé d'Excel, mais avant tout un contributeur comme toi. Je comprends ta frustration devant le fait qu'un bot puisse faire en quelques minutes ce que manuellement tu as patiemment construit année par année. Mais c'est précisément l'avantage de l'informatique, de traiter automatiquement tout ce qui peut l'être pour laisser du temps pour des contributions plus originales, issues de sources autres que l'Insee (historiens, économistes, analystes, voire analyses propres de l'Insee). Et pour un contributeur comme toi qui renseigne pas à pas les articles, il y a des milliers d'autres articles qui ne sont pas renseignés, alors qu'un bot peut le faire. Pour en revenir au cas de 2004 et 2005, le fait de ne pas récupérer toutes les infos est réel, mais je rappelle que le fond du problème est que ces recensements n'ont aucune valeur légale, puisque le premier recensement légal post-1999 est celui de 2006. Je vais ouvrir une section sur le sujet ci-après.Roland45 (d) 19 octobre 2011 à 07:42 (CEST)

• les dates réelles des recensements du XXI^e siècle des petites communes ne sont-elles pas correctes sous Cassini ?

Non, car Cassini, pour les années postérieures à 1999, la seule donnée que Cassini donne est le dernier recensement calé sur l'année 2006, que celui-ci ait été fait en 2004, 2005, 2006 ou 2007 ou 2008. Et peut comporter des erreurs. Prenons le cas d'Ouzouer-des-Champs, dans la fiche Cassini, on voit après 1999 une seule valeur : 292 habitants en 2006. Or le recensement 2008 fait apparaître 356 habitants (voir ici), et celui de 2006 était de 390.Roland45 (d) 18 octobre 2011 à 14:01 (CEST)

Grâce à wikiwix, on peut savoir que les 292 habitants correspondent au recensement de 2005. Ces listes départementales sont malheureusement incomplètes. Il en manque les 2/3. J'ai la liste complète de celles qui sont consultables si ça vous intéresse. Père Igor (d) 18 octobre 2011 à 16:52 (CEST)

Cassini ne fournit, sous l'année 2006, aucun recensement de 2007 ou 2008. Uniquement 2004, 2005 ou 2006. Père Igor (d) 18 octobre 2011 à 17:14 (CEST)

J'aimerais autant éviter le recours à Wikiwix pour ceci, mais c'est à voir en fonction des possibilités.--Juju2004 (d) 18 octobre 2011 à 17:37 (CEST)

A partir de 1999, il faut utiliser exclusivement les fichiers de l'INSEE. Ils donnent les populations légales et font donc foi.Roland45 (d) 18 octobre 2011 à 18:51 (CEST)

• si elles ne sont pas correctes, comment utiliser celles de l'INSEE pour les corriger ?

Il n'est pas question de corriger les données de l'INSEE, ce sont les valeurs légales. A partir de 1999, il convient de les prendre telles quelles (population municipale à partir de 2006, champ P06_POP ouP07_POP ou P08_POP, selon les années).Roland45 (d) 18 octobre 2011 à 14:01 (CEST)

Les dates réelles de recensements des petites communes (tous les 5 ans) peuvent être déterminées (en retirant 5 ou 10 ans) à partir du calendrier de recensement actuel (exemple pour la Dordogne). Père Igor (d) 18 octobre 2011 à 17:14 (CEST)

"Elles" : c'étaient les dates sous Cassini dont je parlais. J'ouvre la section ci-dessous et je reprends l'info de Père Igor.--Juju2004 (d) 18 octobre 2011 à 17:37 (CEST)

• que faire de l'information sur les recensements partiels ? Doit-on l'utiliser pour corriger 2006 en 2005 (par ex.), en lien avec le problème de la mauvaise année attribuée au recensements réels ?

Pour répondre à cela, il convient d'ouvrir une section spéciale, car cela va être un peu long! ... mais je dois y allerRoland45 (d) 18 octobre 2011 à 14:01 (CEST)

Ce sont des questions plus ou moins de détail, mais qui montrent que ça avance.--Juju2004 (d) 18 octobre 2011 à 10:18 (CEST)

Recensements 2004 et 2005

Comment récupérer les données des recensements 2004 et 2005 qui semblent avoir été comptabilisés sur l'année 2006, tant sur le site de l'INSEE que sur Cassini ? Il semble possible de reconstituer le calendrier de recensement des petites communes (pas des grandes ?), donc de déterminer de quand date le recensement pour ces petites communes. Peut-on essayer de mettre en place une démarche fiable à partir de Cassini ou l'INSEE ? (Et si oui, évidemment : laquelle ?)--Juju2004 (d) 18 octobre 2011 à 17:37 (CEST)

Je me réponds à moi-même, après réflexion et prise de renseignements. Est-il est possible de valider les points suivants :

• pour une petite commune recensée en 2004 (et donc la fois suivante en 2009), le "chiffre de population" INSEE de 2006, 2007 et 2008 sera identique à celui du recensement 2004 : il faut donc réattribuer à ce chiffre l'année 2004 ;

Faux. Chaque année, la population peut évoluer en fonction d'estimations légales fournies par l'Insee. Pour les petites communes, nous avions opté au niveau du Projet:Communes de France pour conserver, en dehors du recensement 2004 ou 2005 (quand on peut l'obtenir, vision non partagée par l'ensemble des participants aux discussions), dans les tableaux démographiques, 2006 et le dernier « recensement » en date (donc 2008 pour l'instant). Voir Agonac#Démographie par exemple. Père Igor (d) 18 octobre 2011 à 18:16 (CEST)

• pour une grande commune, les chiffres sont actualisés tous les ans à partir d'un recensement partiel (8% de la population) à partir de 2004. Le "chiffre de population" varie donc tous les ans.

Question :

• peut-on retrouver les extrapolations à partir des recensements partiels 2004 et 2005 pour les grandes communes ? Ou bien ces extrapolations n'ont pas été publiées car trop peu significatives ? Si elles ont été publiées : où les trouve-t-on ?

Pour les communes de plus de 10 000 habitants, nous avions validé le fait de conserver 2006 comme premier recensement du XXI^e siècle, selon cette discussion sur le Projet:Communes de France. Père Igor (d) 18 octobre 2011 à 18:20 (CEST)

• y a-t-il un fichier XLS des dates de recensement des petites communes ?

Pour les petites communes, les seuls calendriers que je connaisse proviennent de l'Insee, soit par wikiwix pour 1/3 des départements français (exemple [5]), soit en calculant la date depuis le calendrier de recensement actuel. Père Igor (d) 18 octobre 2011 à 18:29 (CEST)

Je confirme cette méthode, mais il convient de l'applique que pour les recensements postérieurs à 2006 (voir ci-dessous).Roland45 (d) 18 octobre 2011 à 18:55 (CEST)

J'en profite pour préciser (bien que tu tiennes à tout pris à une récupération par bot) que j'ai déjà établi la table de correspondance pour toutes les communes. J'étais bien obligé pour le script. Et d'ailleurs tu peux la voir dans le fichier excel : feuille "communes", colonne AG intitulée "1ère année recensement". Mais avec la méthode du + ou - 5 ans, tu peux très bien récupérer les données par bot à partir du calendrier de recensement actuel. Mais attention l'an prochain ce calendrier changera peut-être (il est porbable que l'Insee n'affiche plus en 2010 un recensement qui a eu lieu en 2009, il affihera 2014). Ceci risque de perturber le bot si on y pense pas (il suffit en fait de tester l'année de recensement par rapport à l'année en cours (>, = ou <)Roland45 (d) 18 octobre 2011 à 18:59 (CEST)

Si on peut avancer sur ces points, il y a moyen de s'en tirer. Sinon, on pourra toujours mettre une note sur la difficulté et se replacer en 2006.--Juju2004 (d) 18 octobre 2011 à 17:59 (CEST)

La question a déjà été tranchée dans le projet. On ne récupère pas les années 2004 ou 2005. Après 1999, on affiche à partir de 2006 puis tous les recensements réels (pour les petites commuens) à savoir tous les 5 ans.Roland45 (d) 18 octobre 2011 à 18:55 (CEST)

La question a déjà été tranchée, je voudrais juste être sûr d'avoir compris dans quel sens ! Parce que ce tu dis et ce que dit Père Igor n'est pas la même chose, ou bien j'ai mal compris. Pour Père Igor, et pour autant que j'aie bien compris, c'est cela :

• communes de plus de 10 000 habitants : à partir de 2006, tous les cinq ans + dernière population légale. C'est-à-dire pour l'instant : 2006 et 2008.
• communes de moins de 10 000 habitants : si on a un premier recensement réel avant 2006 (2004 ou 2005), le mettre + 2006 + dernière population légale.

Et pour toi (Roland), ce serait plutôt (toujours si j'ai bien compris) :

• communes de moins de 10 000 habitants : à partir de 2006, tous les cinq ans + dernier recensement réel après 2006.

Alors, qu'en est-il ?--Juju2004 (d) 18 octobre 2011 à 20:27 (CEST)

Je ne suis pas d'accord Roland45. C'est sa vision des choses, ce n'est pas la mienne ni celle de tous les participants aux discussions précédentes. L'avis notamment de Utilisateur:GabrieL qui connait l'Insee de l'intérieur est intéressant. Les recensements de 2004 et 2005 gênent principalement les tenants d'une uniformisation qui ne veulent pas voir une oreille dépasser. Le fait d'enrichir un tableau démographique d'une petite commune avec un recensement réel de 2004 ou 2005 me parait normal, du moment que je le justifie par une source, ce que j'ai réussi à faire pour des centaines de communes. Pour moi, Wikipédia est d'abord un projet humain et c'est ce qui m'y a attiré. Si c'est pour déléguer aux bots la mise à jour des articles sans que les utilisateurs puissent encore y apporter une touche supplémentaire, autant laisser tomber de suite. C'est aussi ce que je ressens vis-à-vis de phrases toutes faites que personne ne pourrait modifier. Père Igor (d) 18 octobre 2011 à 22:03 (CEST)

Il ne faut pas tout mélanger. 2006 a été retenu pour avoir une date de départ fiable et communes à toutes les communes correspondant à un écart de 7 ans avec 1999, cohérent avec les écarts précédents et surtout parce que 2004 et 2005 ne sont en fait pas des valeurs légales, lma première étant celle de 2006. Ce n'est pas parce qu'il existe des données qu'il faut les représenter. (même si ce sont des recensements existent et sont réels). Il en est de même pour après 2006, en réalité il faudrait les représenter toutes puisque à partir de 2006 elles sont toutes légales. On a retenuu une convention d'affichage différente (on peut demander à @AntonyB). Pour ce qui est du résumé introductif rien n'empêche de le compléter. Ce qui n'a jusqu'à présent jamais été fait pour les communes que j'ai traitées et pourtant le texte est en clair. Un graphique sans explications, partioculièrement celles reltives aux recensemnets ne veut rien dire.Roland45 (d) 18 octobre 2011 à 22:13 (CEST)

Roland a bien fait d'ouvrir une discussion plus bas sur la question de savoir quels recensements afficher. Je réponds dans la section prévue à la remarque de Père Igor sur les "phrases toutes faites que personne ne pourrait modifier" .--Juju2004 (d) 19 octobre 2011 à 09:38 (CEST)

Quels recensements afficher ?

Les faits réels : après 1999, une réforme du recensement de la population a été mise en place. Les premières populations légales ont été produites en 2006, puis une chaque année. Certaines de ces populations sont issues de recensements réels, d'autres d'évaluations intermédiaires.
A partir de ces éléments se pose la question : quelles données afficher dans le tableau et le graphique ? Les possibilités sont les suivantes :

• Afficher pop 1999 puis toutes les pop à partir de 2006 (2006, 2007, 2008, etc) partant du principe qu'elles sont toutes légales;
• Afficher pop 1999 puis tous les recensements réels en n'affichant pas les recensements issus d'évaluations, sauf le dernier, même si ils sont légaux (dans cette optique on pourrait afficher 2004 et 2005, mais on n'a pas toutes les communes) (option Père Igor);
• Afficher pop 1999 puis 2006 puis tous les recensements réels (pour les com <10000 h) et tous les recensements annuels pour les com >10000 h (c'est l'option retenue dans le script Excel);
• Afficher pop 1999 puis la dernière population légale (c'est l'option retenue par l'Insee)

On peut relancer la discussion, mais pour moi c'est clair et cela me paraissait tranché.Roland45 (d) 19 octobre 2011 à 08:10 (CEST)

La question est bien celle-là, et elle n'est pas technique : je n'ai donc strictement aucun avis là-dessus. Père Igor a fourni une référence de discussion qui semblait pencher dans sa direction, mais sans conclusion définitive. Est-ce que tu as des références d'un endroit où cela aurait été décidé plus formellement (dans un sens ou l'autre) ? S'il n'y en a pas, je pense qu'à ce point, ça vaut le coup de faire une pause et de lancer un sondage sur le projet CDF. Il est hors de question de programmer en encore plus de lancer un bot sans avoir un consensus clair sur ce qu'il doit faire. (Ce qui ne veut pas dire que le bot ne devra jamais évoluer par la suite, mais toujours avec la même exigence : un consensus.) En attendant d'avancer sur ce point, pouvez-vous déjà confirmer que la question ne se pose que pour les commues de moins de 10 000 habitants ?--Juju2004 (d) 19 octobre 2011 à 09:24 (CEST)

Bonjour à tous. Je lis toutes les discussions sur ce sujet depuis plusieurs années et je gère l'archivage au sein du projet, je vais essayer de vous retrouver les conclusions des discussions à ce sujet. Le sondage peut être une bonne solution, mais alors ATTENTION à la formulation de la question. Je constate que dans quasiment tous les sondages faits ici sur WP, les questions sont mal formulées et le résultat est inexploitable (du reste très souvent, il n'y a même pas de conclusion). Un bon exemple est le vote en cours pour lequel chacun interprète à sa façon la question posée. Ok donc pour un éventuel sondage, mais nous devrons être vigilants sur la question posée. Bravo encore pour l'énergie que vous dépensez tous. Cordialement. AntonyB (d) 19 octobre 2011 à 09:35 (CEST)

Il faut bien séparer les deux types de communes : pour celles qui dépassent 10 000 habitants, je pense que les discussions précédentes ne montraient pas de divergences entre les participants. Pour le XXI^e siècle, elles sont recensées très partiellement chaque année. Il semblait acquis qu'on affichait 2006 et la dernière année en date (2008 pour l'instant, donc impasse sur 2007) ; quand on aura quelques années de plus, on pourrait conserver un délai de 5 ans entre les recensements, soit 2006, 2011, et la dernière année en cours. Le point d'achoppement concerne le plus grand nombre : celles qui sont recensées réellement tous les cinq ans. Prenons d'abord celles qui ne devraient pas poser trop de problème : elles ont été recensées en 2006, 2007 ou 2008. On a donc les chiffres légaux de l'Insee correspondants. Je pense qu'il faudra conserver 2006 + la date de recensement réelle + la dernière année en cours, donc s'il s'agit d'un recensement en 2007, on conserve 2006, 2007 et 2008 qui deviendra l'année prochaine 2006, 2007 et 2009, et ultérieurement 2006, 2007, 2012 + dernière année en cours. Dernier cas, le plus sensible, celles qui ont été recensées en 2004 et 2005. Comme vous l'avez déjà compris, je considère que puisque l'Insee a annoncé que le premier recensement de ces communes au XXI^e siècle avait lieu en 2004 ou 2005, il faut, en fonction des sources disponibles (1/3 des départements avec wikiwix, mais existe-t-il d'autres sources ? ), offrir les chiffres provisoires du recensement en question qui pourront ainsi être mis en parallèle avec les futurs recensements de 2009 et 2010. À noter que dans moins de trois mois, l'Insee mettra en ligne le recensement réel 2009 des communes recensées en 2004. Père Igor (d) 19 octobre 2011 à 12:14 (CEST)

Je constate que finalement nous divergeons uniquement sur les années 2004 et 2005. Pour ma part, j'avais retenu le fait de na pas les afficher car elles n'ont jamais été publiées officiellement en tant que populations légales et qu'en tout état de cause on ne les a pas toutes. Mais je ne m'arcbouterai pas sur le sujet. Si cela permet d'éviter un sondage à l'issue incertaine (car effectivement chacun interprète la question à sa façon, sans connaître le sujet) ... et si juju arrive à récupérer les données en question, ok pour afficher 2004 et 2005.Roland45 (d) 19 octobre 2011 à 14:01 (CEST)

Pour ce qui est de la formulation foireuse des questions aux sondages, je confirme, ayant moi-même lancé un sondage "à l'arrache", avec nécessité de préciser les questions en cours de route... Donc, si c'est évitable, évitons. En attendant les informations d'AntonyB, je reformule la solution qui paraît faire consensus entre Père Igor et Roland, en me focalisant sur les années :

• communes qui dépassent 10 000 habitants :
  1. toutes les années avec populations légales publiées parmi 2006, 2011, 2016, etc. (pour l'instant, seulement 2006) ;
  2. dernière année avec populations légales publiées (pour l'instant 2008).
• communes de moins de 10 000 habitants réellement recensées en n (n = 2004, 2005, 2006, 2007 ou 2008) :
  1. toutes les années avec populations officielles publiées parmi n, n+5, n+10, etc. (pour l'instant, seulement n) ;
  2. 2006 (populations légales)
  3. dernière année avec populations légales publiées (pour l'instant 2008).

Pouvez-vous valider cela ?

Ensuite, je voudrais éviter de me retrouver par la suite face à une opposition. On attend donc les conclusions qu'AntonyB va essayer de nous fournir et, en les attendant, j'ai la question suivante : y avait-il d'autres points de divergence au sein du projet que cette question 2004/2005 or not 2004/2005 ?--Juju2004 (d) 19 octobre 2011 à 19:58 (CEST)

Départements d'Outre-mer

En attendant de trouver les informations concernant les recensements des communes des DOM, cette page de l'Insee permet d'accéder aux dates de recensements de chacun des départements d'Outre-mer depuis 1830. Père Igor (d) 21 octobre 2011 à 19:17 (CEST)

Débats sur les modèles à mettre dans les articles de communes

Proposition de texte pour la sous-section « Évolution démographique »

Première partie

Texte proposé

En 2008, Antony comptait 61 240 habitants (soit une augmentation de 2,3 % par rapport à 1999). La commune occupait le 81^e rang au niveau national, alors qu'elle était au 80^e en 1999, et le 9^e au niveau départemental sur 36 communes.

L'évolution du nombre d'habitants est connue à travers les recensements de la population effectués à Antony depuis 1793. Le maximum de la population a été atteint en 2007 avec 61 761 habitants. Au début du XXI^e siècle, les modalités de recensement ont été modifiées par la loi du 27 février 2002, dite « loi de démocratie de proximité », afin de permettre, après une période transitoire courant de 2004 à 2008, la publication annuelle de la population légale des différentes circonscriptions administratives françaises.

Discussion

Pour Je crois que l'on devrait avoir déjà un consensus sur cette première partie de texte. Par contre petite précision dans l'immédiat il faut écarter temporairement un passage qui est "La commune occupait le 81e rang au niveau national, alors qu'elle était au 80e en 1999, et le 9e au niveau départemental sur 36 communes.". En effet, nos modèles de données ne vont pas avoir immédiatement les données concernant les rangs... Mais dès qu'on aura ces données, d'accord pour ajouter ce passage, ça va sans dire. amicalement--Wikialine (d) 19 octobre 2011 à 21:40 (CEST)

Peut-on retirer le bégaiement dans « Au début du XXIe siècle siècle » ? Père Igor (d) 19 octobre 2011 à 23:00 (CEST)

. Voilà, c'est fait. Nous sommes ici sur une page de discussion, n'hésite pas à modifier quand tu vois ainsi des fautes basiques. Cordialement. AntonyB (d) 20 octobre 2011 à 11:32 (CEST)

Seconde partie

Cas des communes de moins de 10 000 habitants

Texte proposé

Pour les communes dont la population est inférieure à 10 000 habitants, les enquêtes sont exhaustives et ont lieu chaque année par roulement au cours d'une période de cinq ans.

Pour Ascoux, le premier recensement a été fait en 2005, les suivants étant en 2010, 2015, etc. La première population légale postérieure à celle de 1999 et s’inscrivant dans ce nouveau dispositif est entrée en vigueur au 1^er janvier 2009 et correspond au recensement de l’année 2006, qui, pour Ascoux, est une évaluation intermédiaire. Le premier recensement exhaustif est celui de 2010, qui sera publié en 2013. Pour cette période 2006-2010, la population 2006 ainsi que la dernière population légale publiée par l’Insee sont présentées pour information.

Le maximum de la population a été atteint en 2008 avec 869 habitants.

Variante proposée pour la seconde phrase

Pour Bagiry, cela correspond à 2007, 2012, etc.. Les données pour les autres années de « recensement » (2006, 2008, etc.) sont des estimations légales.

Discussion

Le script Excel comporte également la phrase suivante :« La première population légale postérieure à celle de 1999 et s’inscrivant dans ce nouveau dispositif est entrée en vigueur au 1^e janvier 2009 et correspond au recensement de l’année 2006, qui, pour Ascoux, est une évaluation intermédiaire. Le premier recensement exhaustif est celui de 2009, publié en 2012. Pour cette période 2006-2009, la population 2006 ainsi que la dernière population légale publiée par l’INSEE sont présentées pour information. » C'est peut-être complexe à comprendre pour celui qui n'est pas ds le bain de ces recensements réels/intermédiaires, mais c'est précis.Roland45 (d) 20 octobre 2011 à 09:09 (CEST)

Intéressant, mais lire en 2011 que quelque chose a été « publié en 2012 », c'est de la prédiction. Le temps que le bot fonctionne, ça sera résolu mais le problème demeure pour les communes recensées en 2005 dont on ne connaîtra, si tout va bien, le recensement 2010 qu'en 2013. Je pense donc qu'il faudrait un test par rapport à cette date d'édition pour écrire la phrase au futur (qui sera publié en 2013). Père Igor (d) 20 octobre 2011 à 11:24 (CEST)

Merci de vos commentaires que j'ai donc pris en compte. Cordialement. AntonyB (d) 20 octobre 2011 à 11:47 (CEST)

Cas des communes de plus de 10 000 habitants

texte proposé

Pour les communes dont la population est supérieure à 10 000 habitants, une enquête par sondage est effectuée chaque année. La totalité du territoire de ces communes est prise en compte au terme d'une période de cinq ans. La première population légale postérieure à celle de 1999 et s’inscrivant dans ce nouveau dispositif correspond au recensement de l’année 2006. Elle est entrée en vigueur au 1^er janvier 2009.

Discussion

Autre suggestion (phrases plus courtes, ordre des propositions, levée de l'ambiguïté concernant la « même période ») : « Pour les communes dont la population est supérieure à 10 000 habitants, une enquête par sondage est effectuée chaque année. La totalité du territoire de ces communes est prise en compte au terme d'une période de cinq ans. La première population légale postérieure à celle de 1999 et s’inscrivant dans ce nouveau dispositif correspond au recensement de l’année 2006. Elle est entrée en vigueur au 1^er janvier 2009. »

Merci pour tes judicieuses remarques que j'ai donc prises en compte. Cordialement. AntonyB (d) 20 octobre 2011 à 11:52 (CEST)

Génération automatique du résumé introductif

Je ne sais pas ce qui est entendu par là, mais cette question de la génération automatique d'un résumé introductif a déjà été soulevée à d'autres sujets (je n'ai plus retrouvé, mais c'était à propos d'article répétitifs, genre caractères japonais). Ça semble une idée plus que discutable, dans la mesure où le contributeur ne peut pas modifier ce résumé, et souvent ne comprend même pas d'où vient ce résumé.--Juju2004 (d) 30 septembre 2011 à 13:36 (CEST)

Je n'ai travaillé que sur les modèles bdd, tableau de pop et graph. Roland à émis l'idée de plancher sur un modèle d'intro... Je crois que dans l'immédiat pour éviter de se dispercer on devrait travailler sur les modèles bdd (ou autre nom), le tableau unique de la population et le graphique. Après on développera d'autres applications. ça évitera que l'on se perde dans les débats.--Wikialine (d) 30 septembre 2011 à 17:24 (CEST)

Sur ce point, je pense comme toi qu'il faut essayer de se concentrer sur la première partie (population et graphe). Mais si tu peux inviter Roland (et d'autres) à venir discuter ici de la question de l'intro automatique, ça m'intéresse. Car, autant les points ci-dessus sont presque exclusivement techniques et je pense pouvoir te montrer assez rapidement des solutions probantes, autant celui-ci doit être discuté plus largement.--Juju2004 (d) 1 octobre 2011 à 10:39 (CEST)

Suite à certaines demandes émises ici ou là, ayant eu un peu de temps libre, j'ai commencé à plancher sur un générateur de texte introductif. Pour en voir la démonstration, il vous suffit de consulter la page de test suivante : Projet:Communes de France/Mise à jour automatique des données démographiques/Antony en regardant l'exemple avec le modèle {{Section démographie d'article de commune de France}}. Je me suis efforcé de reprendre une partie du texte que générait l'ancien script de Roland45. J'ai par contre retiré la ligne « La commune occupait le Xe rang au niveau national, alors qu'elle était au Xe en 1999, et le Xe au niveau départemental sur X communes. », car pour le moment les modèles données ne contiennent pas les données sur les rangs nationaux et départementaux... On pourra très facilement ajouter cette ligne lorsque les modèles données contiendront ces informations. amicalement--Wikialine (d) 18 octobre 2011 à 02:10 (CEST)

Très bien ce premier modèle. Pour rappel, il y a en fait deux résumés introductifs, un pour chaque section : évolution de la population d'une part et pyramide des âges d'autre part.Roland45 (d) 18 octobre 2011 à 07:53 (CEST)

J'ai fait avec les données dont on dispose pour le moment. Mais effectivement tu as raison par la suite, lorsque l'on aura les données des pyramides des âges ainsi que les rangs.... alors il faudra compléter le modèle {{Section démographie d'article de commune de France}}, ce qui se fera facilement. amicalement--Wikialine (d) 18 octobre 2011 à 20:22 (CEST)

La critique des résumés introductifs empêchant l'ajout de texte reviendra assurément. Il faut donc pouvoir s'en affranchir et tout contributeur doit pouvoir ajouter du texte. Par expérience, les quelques ajouts qui peuvent être faits sont des ajouts historiques expliquant tel ou tel pic à telle ou telle époque en lien avec tel ou tel mouvement de population ou événement historique ou la nature d'un plateau du graphique. En fait il suffit de générer le résumé introductif en 2 modèles. Le premier donne une vision synthétqiue des chiffres et amorce un début d'historique :

Modèle 1 : "En 2008, Ouzouer-des-Champs comptait 356 habitants (soit une augmentation de 29 % par rapport à 1999). La commune occupait le 20 243e rang au niveau national, alors qu'elle était au 22 236e en 1999, et le 232e au niveau départemental sur 334 communes. L'évolution du nombre d'habitants est connue à travers les recensements de la population effectués à Ouzouer-des-Champs depuis 1793."

et le 2ème est ciblé sur les derniers recensements

Modèle 2 : "Au début du XXIe siècle, les modalités de recensement ont été modifiées par loi du 27 février 2002, dite loi de démocratie de proximité[2], afin de permettre, après une période transitoire courant de 2004 à 2008, la publication annuelle de la population légale des différentes circonscriptions administratives françaises. Pour les communes dont la population est inférieure à 10 000 habitants, les enquêtes sont exhaustives et ont lieu chaque année par roulement au cours d'une période de cinq ans[3]. Pour Ouzouer-des-Champs, le premier recensement a été fait en 2005[4], les suivants étant en 2010, 2015, etc. La première population légale postérieure à celle de 1999 et s’inscrivant dans ce nouveau dispositif est entrée en vigueur au 1e janvier 2009 et correspond au recensement de l’année 2006, qui, pour Ouzouer-des-Champs, est une évaluation intermédiaire. Le maximum de la population a été atteint en 2007 avec 394 habitants.

Entre les deux tout peut être ajouté.Roland45 (d) 19 octobre 2011 à 07:57 (CEST)

Quelques informations qui peuvent faire avancer le débat :

• la question a déjà été débattue au moins une fois sur le Bistro. La tendance était plutôt contre, mais la situation n'était pas exactement la même : texte généré par l'infobox ;
• il y a la possibilité de "subster" un modèle, c'est-à-dire de le remplacer par son contenu. Le texte apparaît ainsi en clair, bien qu'ayant été généré automatiquement. Les appels aux modèles contenant les données spécifiques peuvent être maintenus (ex. max de population, année du max, etc).

--Juju2004 (d) 19 octobre 2011 à 09:43 (CEST)

Ce "substage" parait être l'idéal. Mais attention, si le texte en clair est modifié, il faudra que le bot puisse le détecter lors du passage suivant pour sortir une liste des pages qu'il conviendra de revoir en fonction des ajouts qui auront été faits (mais par expérience, il ne devrait pas y en avoir beaucoup!).Roland45 (d) 19 octobre 2011 à 14:08 (CEST)

Je suis extrêmement réservé vis-à-vis du "substage". Il important de promouvoir l'uniformisation des séries d'article. Avec un modèle comme {{Section démographie d'article de commune de France}}, on peut rendre plus uniforme nos articles. Cela donne un rendu plus professionnel pour nos article, les visiteurs s'y retrouve plus facilement d'un article à un autre si ils ont une présentation commune. Et très important, on diminue de façon notoire les conflits d'édition. Certains veulent un type de graphique et d'autre pas, certains veulent de large tableau, d'autres pas... C'est pourquoi, i vaudrait mieux travailler sur un concept de modèle semi rigide comme avec le modèle {{Section démographie d'article de commune de France}}. On a ainsi une présentation identique sur tous les articles mais en laissant la possibilité aux rédacteurs d'ajouter du contenu (voir les paramètre optionnels que je viens d'ajouter...). amicalement--Wikialine (d) 19 octobre 2011 à 20:04 (CEST)

Je voulais répondre à Roland et me voici parti pour répondre à Aline ! Le rendu plus pro, etc. ok. Mais pour la diminution des conflits, tu risques de déchanter : il y aura certainement des conflits entre ceux qui acceptent le modèle et ceux qui le refusent et des conflits sur le contenu du modèle lui-même. Et comment vas-tu imposer le "non-substage" ? Un conflit de plus ! Je l'ai déjà écrit ailleurs sur cette page : les blocages techniques ne sont pas la solution aux conflits ; c'est le consensus qui est la solution... même si c'est moins confortable.

Pour ce qui est du "substage" point de vue technique, on doit pouvoir se débrouiller pour conserver en variable les infos qui changent. Par exemple, pour Antony, on pourrait avoir en clair dans le texte de l'article :

En {{Données/Antony/évolution population|an}}, Antony comptait {{formatnum:{{Données/Antony/évolution population|pop}}}} habitants...

Ce qui laisse quand même de la marge pour préciser, reformuler si nécessaire, etc. Attention : il faut travailler le modèle pour que ça marche comme on veut.

Le problème vient lorsqu'on arrive au passage "...soit une augmentation/une diminution/aucune évolution par rapport..." car évidemment, des expressions sont choisies en fonction des valeurs fournies. Mais on doit pouvoir arranger les modèles pour limiter les expressions toutes faites. Je regarderais cela plus tard, j'ai déjà vu que les modèles pouvaient être améliorés (techniquement parlant, évidemment), substage ou non.--Juju2004 (d) 19 octobre 2011 à 20:27 (CEST)

Commentaire d'AntonyB le 19 octobre 2011 à 19h01

Bonjour.

• Pour votre info : je viens de m'ajouter à la liste des contributeurs, et je viens de corriger quelques fautes d'orthographe, de typo et de syntaxe wiki dans le texte à ajouter après le tableau au sein du modèle {{Section démographie d'article de commune de France}} pour les communes de plus de 10 000 habitants.
• Question : où se trouve les texte pour les communes de moins de 10 000 habitants ?
• Pour Roland45 : à l'occasion, dans une prochaine mise à jour de ton script, tu pourras reprendre ce texte corrigé. Il me semblait te l'avoir transmis un jour, mais j'ai peut-être oublié.

Cordialement. AntonyB (d) 19 octobre 2011 à 19:01 (CEST)

(Re) bonjour et (re) bienvenue parmi les contributeurs. Et merci d'être intervenu, en particulier sur le point assez chaud des recensements à afficher. Pour la question du résumé introductif, il y a une section dédiée si tu veux en discuter plus avant.--Juju2004 (d) 19 octobre 2011 à 19:33 (CEST)

Je pense qu'il existe plusieurs formulations proches les unes des autres. Regarde par exemple celle que j'ai appliquée sur Bagiry#Démographie. Père Igor (d) 19 octobre 2011 à 21:15 (CEST)

Bonjour. Merci de l'info. J'ai repris ce texte (voir plus haut) mais en le corrigeant car il n'est pas correct d'écrire que les dates sont des estimations légales. Une date, c'est une date, pas une estimation légale. J'ai proposé ci-dessus une reformulation ... à discuter ! Bien cordialement à tous. AntonyB (d) 19 octobre 2011 à 21:54 (CEST)

Autre proposition : un cartouche

Je reviens sur ce point du résumé introductif, qui pose pas mal de problèmes (gel de texte en particulier), pour suggérer une possibilité. Pourquoi ne pas substituer à un résumé en bon français un simple cartouche, un genre d'infobox de section qui reprendrait sous forme de tableau les informations brutes (population au dernier recensement) ou calculées (type variation de population) ? C'est bien sûr moins joli, mais ça a plusieurs avantages :

• ça évacue les conflits d'édition dans les articles (un tableau est un tableau, une donnée est une donnée) ;
• ça uniformise autant qu'un texte figé ;
• si le cartouche est seul, on comprend qu'aucun "contenu éditorial" spécifique n'a été ajouté pour cette commune (ce qui est plutôt normal pour la plupart des communes). On ne fait pas comme si le texte avait été rédigé alors que c'est un texte automatique ;
• on peut rajouter du texte libre si nécessaire ;
• s'il y a du texte libre, on peut le modifier et l'améliorer.

Exemples :

Antony

premier recensement :	1793
dernier recensement :	2008
population en 2008 :	61 240 habitants
variation par rapport 1999 :	augmentation de 2.31 %
Les modalités de recensement ont été modifiées par la loi du 27 février 2002, dite « loi de démocratie de proximité », afin de permettre, après une période transitoire courant de 2004 à 2008, la publication annuelle de la population légale des différentes circonscriptions administratives françaises. Pour les communes dont la population est supérieure à 10 000 habitants, une enquête par sondage est effectuée chaque année. La totalité du territoire de ces communes est prise en compte au terme d'une période de cinq ans. La première population légale postérieure à celle de 1999 et s’inscrivant dans ce nouveau dispositif correspond au recensement de l’année 2006. Elle est entrée en vigueur au 1er janvier 2009. .

ou :

Antony

premier recensement	dernier recensement	population en 2008	variation par rapport 1999
1793	2008	61 240 habitants	augmentation de 2.31 %
Les modalités de recensement ont été modifiées par la loi du 27 février 2002, dite « loi de démocratie de proximité », afin de permettre, après une période transitoire courant de 2004 à 2008, la publication annuelle de la population légale des différentes circonscriptions administratives françaises. Pour les communes dont la population est supérieure à 10 000 habitants, une enquête par sondage est effectuée chaque année. La totalité du territoire de ces communes est prise en compte au terme d'une période de cinq ans. La première population légale postérieure à celle de 1999 et s’inscrivant dans ce nouveau dispositif correspond au recensement de l’année 2006. Elle est entrée en vigueur au 1er janvier 2009.

Voilà. Je ne sais pas si ça convient à ce que vous attendez, mais il me semble que le procédé est moins contestable qu'un texte figé généré par modèle. Il est possible de mettre le texte sur les communes de plus de 10 000 habitants dans les articles sur ces communes, un autre texte dans les articles sur les autres.--Juju2004 (d) 20 octobre 2011 à 11:17 (CEST)

Bonjour. Ces propositions sont très intéressantes. Je viens de corriger quelques erreurs de typo et de syntaxe dans ces tableaux. Ma préférence va incontestablement à ton second tableau. Cordialement. AntonyB (d) 20 octobre 2011 à 12:28 (CEST)

Pour ma part je préfère la même chose mais en texte (en clair ou en modèle), pas en infobox qui vient se rajouter au grpahique en-dessous. Seul du texte peut précéder un graphique.Roland45 (d) 20 octobre 2011 à 12:38 (CEST)

Je comprends tout à fait l'argument. La forme d'un cartouche n'est pas idéale, mais vise juste à souligner que les informations sont générées automatiquement (et n'ont pas vocation à être modifiées sauf exception), ce qui est le cas. Donc à ne pas faire croire qu'on a quelque chose de "personnalisé" pour la commune... et donc de personnalisable : "il y a un texte écrit qui ne me convient pas, je veux le modifier..." et c'est le début des difficultés soulignées par Aline en ce qui concerne l'unité des articles, les conflits, la mise à jour, etc. Après, pour être clair, je n'ai strictement aucune intention d'essayer d'imposer une solution de ce genre (même si j'en vois directement les avantages pour la mise à jour des articles). Vous voyez...--Juju2004 (d) 20 octobre 2011 à 21:21 (CEST)

Je connais bien les gouts des membres du projet CDF et je suis certaine que la solution de la cartouche sera écartée d'office. Il vaut mieux un petit texte généré automatiquement avec une possibilité d'ajout de contenu libre. --Wikialine (d) 20 octobre 2011 à 21:53 (CEST)

Méthode 1 - Modèle Section démographie d'article de commune de France

Afin de s'y retrouver dans nos débats, j'ouvre ici une discussion ciblée sur le modèle {{Section démographie d'article de commune de France}}. Je rappel que pour avoir un exemple du fonctionnement de ce modèle, vous pouvez aller sur la page Projet:Communes de France/Mise à jour automatique des données démographiques/Antony#Modèle Section démographie

1. Comparaison avec les données 1999, J'ai mis un système de calcul en pourcentage du taux d'évolution entre l'année 1999 et le dernier recensement. Le script de calcul se trouve dans le sous-modèle {{Section démographie d'article de commune de France/Calcul taux comparatif 1999}}. Suivant l'évolution de la population par rapport aux données de 1999, 3 types de parenthèses peuvent apparaître, l'une précise une augmentation, l'autre une diminution et la dernière indique l'égalité. Le modèle {{Section démographie d'article de commune de France}}, a un script de recherche de l'année 1999 dans les modèles de données. Ainsi il y a également une prise en compte d'une absence de recensement de cette année et le texte introductif est donc mis à jour en conséquence.
2. Ajout de contenu supplémentaire, Comme l'a dit plus haut Roland (Rappel :« La critique des résumés introductifs empêchant l'ajout de texte reviendra assurément. Il faut donc pouvoir s'en affranchir et tout contributeur doit pouvoir ajouter du texte. »), il faut effectivement permettre aux rédacteurs d'ajouter des informations dans la section démographie. Ainsi j'ai créé 3 paramètres optionnels (contenu 1, 2 et 3) permettant aux rédacteurs d'ajouter du contenu dans la section.

amicalement--Wikialine (d) 19 octobre 2011 à 21:08 (CEST)

Méthode 2 - Le substage

Précision technique : le substage consiste, en utilisant le mot-clé subst, a remplacer un modèle par son contenu. Ce substage peut-être réalisé sur le modèle lui-même, les sous-modèles dans le modèle (si souhaité), etc. jusqu'au niveau souhaité. Le "substage" peut donc être total ou partiel.--Juju2004 (d) 20 octobre 2011 à 10:50 (CEST)

Je suis extrêmement réservé vis-à-vis de cette méthode pour plusieurs raisons (qui ne sont ap^s insurmontable et qui pour beaucoup, j'en conviens sont subjectives, tout ça pour dire que je ne suis pas totalement opposé à cette méthode même si je préfèrerais la méthode 1 à savoir l'usage d'un modèle de section) :

1. L'un des objectifs majeurs de ce projet de mise à jour automatique des données est de faire en sorte que le contenu des articles de communes françaises soient plus simple à tenir à jour. Certains articles sont en déshérences, en mettant en inclusion un modèle du type {{Section démographie d'article de commune de France}} (méthode 1), on aura juste à coller une seule fois ce script dans les articles et après on n'a plus besoin d'intervenir dans les articles (sauf si on veut ajouter des informations complémentaires éventuellement). L'essentiel du travail est fait automatiquement et est toujours tenu à jour par le modèle unique. En revanche avec le substage, on va devoir continuer à devoir intervenir dans les articles. Même si l'on utilise un bot ça reste une solution de complication à mon sens (programmation supplémentaires...).
2. En utilisant un modèle de section comme dans la méthode 1 ({{Section démographie d'article de commune de France}}), on permet une meilleurs harmonisation d'une série d'articles que sont les articles de communes françaises. Avoir une présentation identique partout est un gage de qualité d'après moi. Avec le substage ça sera difficile de définir une présentation identique sur chaque article (n'oublions pas que l'on parle d'une série de plus de 36 600 articles). Certains mon retirer des données d'autres modifier la présentation et j'en passe.
3. Le substage n'est pas pratique pour la mise à jour des articles. En effet, aujourd'hui on travail dans un 1er temps sur l'ajout de données concernant les recensements de la population. Mais demain on pourra plancher sur l'ajout d'autres données démographiques comme la pyramide des ages, les rangs nationaux et départements et j'en passe. A chaque ajout de nouvelles données dans les modèles de données, il faudra un ou des modèles qui lisent ces données et les mettent en forme dans les articles. Si on utilise un modèle du type de la méthode 1 comme {{Section démographie d'article de commune de France}}, dans ce cas pas de problème, on modifie juste ce modèle et la totalité des article est immédiatement mise à jour. En revanche si l'on utilise la méthode du substage, il faudrait encore programmer un bot pour ajouter le nouveau contenu dans les articles avec toutes les difficultés que cela représentes (toutes les sections sur la démographie n'ont pas le même libellé...).

Voilà une partie de mes craintes vis-à-vis du substage et qui me font préférer l'usage d'un modèle unique comme {{Section démographie d'article de commune de France}}. Mais bon, mon avis n'est pas définitif et je reste ouverte au débat sur ce domaine et de toute façon, ce sera les wikipédiens dans leur ensemble qui trancheront en la matière. amicalement--Wikialine (d) 19 octobre 2011 à 21:26 (CEST)

Tableau

discussion temporairement close (n'hésitez pas à la rouvrir)

Pour le tableau, j'ai trouvé le modèle {{Démographie2}} qui m'a l'air de faire à peu près ce qui est souhaité. Je me suis attaqué à une mise à jour du modèle (il comporte quelques imperfections), car on peut facilement brancher les données dessus :

{{Démographie2
|titre=Évolution de la population de {{PAGENAME}}
|colonnes=12
|années-fond=#CCCCCC
|population-fond=#FFFFFF
|{{Données Population/{{PAGENAME}}/évolution|an1}}|{{Données Population/{{PAGENAME}}/évolution|pop1}}
|{{Données Population/{{PAGENAME}}/évolution|an2}}|{{Données Population/{{PAGENAME}}/évolution|pop2}}
|...
}}

Ce n'est qu'un exemple, mais je crois qu'il vaut mieux partir d'un existant qui a l'air de fonctionner à peu près que de recommencer à zéro.--Juju2004 (d) 2 octobre 2011 à 22:25 (CEST)

Je me suis permise de scinder en 2 ton message, afin de faciliter la discussion qui porte sur 2 sujets importants. Pour le tableau, il vaut mieux utiliser le modèle {{Tableau Population Commune}} qui est quasiment terminé. Je connais assez bien le modèle Démographie2, j'y ai contribué. Je suis très réservé sur l'enchevêtrement de modèles et à plus forte raison lorsqu'il s'agit de plus de 36600 articles. Par ailleurs, le modèle Démographie2 mériteraient d'être fusionné avec d'autres modèles (démographie...). Je préfère la stabilité en utilisant un modèle indépendant et si possible générique. J'ai beaucoup de craintes vis-à-vis de cette successions de modèles, je ne te la cache pas.--Wikialine (d) 3 octobre 2011 à 12:53 (CEST)

No problem pour le découpage. Je t'avoue que je préfère l'idée d'un modèle configurable dès l'origine (comme {{Démographie2}}). Je sais que tu n'es pas de cet avis, mais je sais aussi que si le modèle n'est pas configurable, quelqu'un cherchera forcément à le rendre configurable. Et il y arrivera, d'une manière ou d'une autre, et probablement de la mauvaise... Donc si tu veux imposer une certaine présentation, ce n'est pas par des limitations techniques qu'il faut passer, mais par un consensus. Cela dit, il va de soi que le modèle doit pouvoir être utilisé sans aucun paramètre, de la manière la plus simple qui soit.

Sur le point technique, il existe pas mal de modèles qui appellent eux-mêmes des modèles sans que ça pose le moindre problème : c'est exactement comme découper un programme en fonctions. Pour éviter de discuter dans le vide, je crois que le mieux est la preuve par l'exemple. Donc je vais d'abord publier une version retravaillée de {{Démographie2}} (ce soir). Ensuite, je créerais un modèle Projet:Communes_de_France/Mise_à_jour_automatique_des_données_démographiques/Tableau Population Commune, une petite table bidon Projet:Communes_de_France/Mise_à_jour_automatique_des_données_démographiques/Données population/Commune test/évolution et une page de test Projet:Communes_de_France/Mise_à_jour_automatique_des_données_démographiques/Commune test. Et puis on pourra discuter du résultat. Si ça ne te convient pas, il sera toujours possible de rester sur le modèle {{Tableau Population Commune}} actuel.--Juju2004 (d) 3 octobre 2011 à 13:51 (CEST)

 Fait. Il reste à fignoler, mais c'est pour te montrer que ça marche : Projet:Communes_de_France/Mise_à_jour_automatique_des_données_démographiques/Commune test.--Juju2004 (d) 3 octobre 2011 à 21:47 (CEST)

Tu sembles très attaché à l'usage du modèle Démographie2 alors va pour cette voie, c'est d'accord. Par contre je suis viscéralement attaché à la généracité et à l'harmonisation des modèles employés dans les articles. Je me suis battu 3 ans pour harmoniser les infobox de communes françaises (avant il y avait 12 modèles d'infobox doublon pour les communes françaises). C'est un combat qui rend très impopulaires mais qui est très payant à la sortie car on diminue les conflits d'édition dans les articles où avant cela les rédacteurs imposaient leurs propres choix en matière de charte graphique... On doit tendre vers l'harmonisation des séries d'articles. En tant que membre du projet communes de france, j'ai été témoins de nombreux débats houleux sur le choix de la présentations des articles et j'en passe. Tout ça pour te dire, qu'il est primordial de développer un modèles générique et qui limite les possibilités de paramétrage. Ainsi comme voie médiane je te propose le modèle suivant {{Tableau Population}}. Je t'ai mis des exemples sur la page TEST. J'y ai intégré ta proposition d'usage du modèle Démographie2, et j'ai ajouté un paramètre unique intitulé Charte (comme cela existe dans bien d'autres modèles). Ainsi on est sûre d'éviter les dérives du passé en matière de présentation. J'ai également remis en bas du tableau le lien Base de donnée. C'est très important d'ajouter ce lien car il indique aux wikipédiens où se trouvent les données du tableau et explique aux utilisateurs comment fonctionne le système de mise à jour. C'était une volonté émise par certains membres du projet cdf et moi même. J'ai conservé le nom de base de donné, car cette fois-ci même si ce n'est pas réellement une base de donnée, pour les wikipédiens lambda cette appellation est la plus simple et la plus évidente. ça sera plus parlant pour eux et à coté de cela pour les techniciens appelons nos modèles "Données" comme tu l'as proposé et où je te suis à 100 %. J'ai essayé de remettre une présentation respectant la volonté de plusieurs membres du projet cdf. J'ai également wikifié les dates. C'est une des chartes employées notamment par exemple sur l'articles ADQ Royan. Si tout cela te convient un peu près je te laisse finaliser le modèle {{Tableau Population}}. Pour les essais, créé directement un modèle Donnée, ce sera plus simple. amicalement--Wikialine (d) 3 octobre 2011 à 23:35 (CEST)

Sur tes remarques :

• pour ce qui est de limiter les paramètrages, je suis plutôt d'accord sur le principe, mais, comme dit plus haut, je pense que cela ne doit pas être le résultat de contraintes techniques. L'idée est de construire le meilleur outil possible, puis de laisser le projet décider de ce qu'il veut en faire. Va donc pour un modèle {{Tableau Population}} avec un paramétrage minimal : s'il se dégage un consensus pour desserrer la contrainte (par ex. choix du nombre de colonnes ou placement du tableau à gauche ou à droite), il sera plus simple de changer deux lignes dans le code que d'avoir à tout repenser depuis le départ.
• pour ce qui est de mettre un lien vers la base de données, c'est une très bonne idée, y compris pour le terme "base de données", puisqu'ici on se doute qu'on ne va aller voir l'ensemble de la base mais une partie des données. Je vais juste faire rentrer ce lien dans le modèle {{Démographie2}} où il a sa place, plutôt que de le laisser traîner en dehors.
• je n'ai pas créé ou modifié directement un modèle de données, parce que je ne sais pas trop s'ils sont utilisés actuellement. Comme je voulais avoir les paramètres nommés "an" et "pop", j'ai préféré en créer un fictif pour les tests.

Deux autres remarques :

• j'ai lourdement restructuré {{Démographie2}}, donc si tu vois des problèmes, fais-les moi remonter.
• le modèle {{Tableau Population}} dans sa forme actuelle ne fonctionne que pour la "Commune test", puisque l'appel au modèle des données est paramétré pour. Je vais corriger ça et fignoler le reste.--Juju2004 (d) 4 octobre 2011 à 09:22 (CEST)

Questions bonus : {{Démographie2}} n'a pas de fond par défaut pour les populations, mais utilise {{Charte de couleur}} pour les années, en fonction d'un paramètre {{{charte}}}. Ce modèle est-il d'actualité ? Faut-il mettre en couleur les années ou les populations ? Je pencherais plutôt pour les années afin de laisser l'information population (parfois plus difficile à appréhender d'un coup d'oeil lorsqu'il y a plus de trois chiffres) sur fond neutre.--Juju2004 (d) 4 octobre 2011 à 10:27 (CEST)

Pour la question bonus, concernant le modèle Charte, je passe. Pour ce qui est de la couleur, avec Roland et d'autres on avait discuté de la présentation du tableau. La tendance actuelle penche en faveur du fond gris pour les années et d'un fond vert (ton faible) pour la population. Cette charte est utilisé sur certains Adq comme Royan, Chamonix, Annecy, Antony. J'ai mis cette charte en place dans l'exemple que je t'ai mis dans la page test. De toute façon si ultérieurement, certains veulent débattre à nouveau des couleurs, alors il suffira de faire un simple sondage (ça évite les querelles dans ce genre d'histoire) et de modifier la charte graphique en conséquence. Mais bon là je suis confiante. Pour la wikification systématique des dates, c'est un impératif. Personnellement tout me va du moment que l'on respect le code couleur classique pour un article de commune (usage de de tons verts fort ou faible et de tons gris). Pour le moment conserve la présentation que j'ai mis, ça devrait aller. Pour le reste, si tu veux tenter d'intégrer le lien "voir base de données" dans le tableau directement, ça me dérange pas. Dans mes quelques essais ça me semblait plus intuitif mais personnellement tout me va à ce niveau là, je te laisse trancher. On peut passer à la modification du modèle {{Tableau Population}} afin qu'il fonctionne avec des noms de modèles normaux. Pour nos futurs tests, on s'épargnera du travail supplémentaire. Et ça ne posera pas de soucis, car ces modèles ne sont pas utilisés sur les articles. On est les seul à travailler dessus. amicalement--Wikialine (d) 4 octobre 2011 à 14:35 (CEST)

Dans l'ordre :

• pour les couleurs, ce serait gris pour les années, et la charte pour les populations (voir le modèle {{Charte de couleur}}) ? ;
• pour les dates il n'y à qu'à mettre le paramètre (tu l'as déjà fait). Une remarque à ce sujet (mais je n'insisterai pas) : c'est un wikilien hors contexte, donc pas forcément pertinent ;
• je préfère rester dans des sous-pages projet pour les tests, parce qu'on risque de polluer le main autrement. Ça permet également que tu modifies les modèles à ta guise, et que je puisse mettre tout ça au clair sur un modèle indépendant.--Juju2004 (d) 4 octobre 2011 à 17:51 (CEST)

Le gris pour les années on est d'accord, par contre les couleurs du modèle {{Charte de couleur}}) sont contradictoires avec celles que l'on recommande généralement dans d'autres projets. Je suis une membre active du projet Commune de France et du Projet Infobox, c'est dire si la question des couleurs revient régulièrement sur le tapi. Malgré des divergences ici ou là et surtout un manque d'intérêt de la communauté wikipédienne pour les questions d'harmonisation des chartes graphiques. Toujours est-il que la règle générale est la suivante :

	Niveau 1	Niveau 2	Niveau 3	Niveau 4	Niveau 5
Couleur forte	#DDFFDD	#ECE5CA	#E1E1E1	#E0DBB6	#BBDEFD
Couleur faible	#F3FFF3	#FAF9EC	#F1F1F1	#F6F3DD	#F2F6FE

Il y a d'ailleurs un rappel sur la page Projet:Charte graphique/Domaine géographique, sans oublier les rappels fait dans des documentations de modèles ici ou là. Ce qui est sûre c'est que les tons foncés ne sont pas vraiment cohérents dans le tableau, il vaut mieux les tons faibles. J'ai d'ailleurs ajouté des exemples dans la pratique Antony, Chamonix, Royan, Annecy... Le modèle {{Charte de couleur}}) me paraît bien curieux sur le fond donc car il propose des couleurs contradictoires avec d'autres recommandations. Et sur la forme, je le trouve un peu déroutant car en paramètre 1 j'aurai mis "nom de la charte" certes mais en y mettant dedans : commune, intercommunalité, canton, région... Puis dans le paramètre 2, je mettrait un indicateur ton fort ou faible tout simplement. Il vaudrait mieux utiliser les tons faibles à mon sens, à toi de voir même si de toute façon, les membres du CDF vont surement se saisir eu même de cette question de choix des couleurs in fine. En tout cas cela reste un détail vert foncé ou clair à la sortie, les 2 se valent, moi ça me va, on est un peu près dans les clous.--Wikialine (d) 4 octobre 2011 à 21:08 (CEST)

Je n'y connais rien à ces codes couleurs, donc je vais plutôt te suivre, mais je veux bien quelques explications car il n'y a pas de raison de laisser traîner le modèle {{Charte de couleur}} en l'état s'il est faux. Si je comprends bien le code couleur exposé et le Projet:Charte_graphique/Domaine_géographique, on a ceci (pour la France) :

	Niveau 1	Niveau 2	Niveau 3	Niveau 4	Niveau 5
Type	Commune	Canton (et arr.)	Arrondissement	Département	Région
Couleur forte	#DDFFDD	#ECE5CA	#E1E1E1	#E0DBB6	#BBDEFD
Couleur faible	#F3FFF3	#FAF9EC	#F1F1F1	#F6F3DD	#F2F6FE

Ce qui signifie que la charte "communes" est respecte le code couleur fort, avec une erreur sur le département (#f6f3dd vs. #E0DBB6 selon le code) en ajoutant l'intercommunalité (#ffe2bf inconnu du code, mais présent sur {{Infobox Intercommunalité de France}} donc plus ou moins acceptable) ; la charte "communes contraste" est originale ; il n'existe pas d'équivalent pour le code couleur faible. Il faudrait donc, si j'ai bien compris, faire la correction sur "communes", ajouter une charte "communes pastel" (ou autre nom à trouver) et déconseiller "communes contraste". Je sais bien que ce n'est pas l'essentiel (l'essentiel est dans la rubrique "question légale" pour l'instant) mais ça m'intéresse d'améliorer les choses d'autant plus que ce modèle est utilisé dans les pyramides des âges par ex.--Juju2004 (d) 4 octobre 2011 à 22:03 (CEST)

En matière de charte graphique, c'est une lutte permanente, j'ai beaucoup œuvré pour faire avancé ce dossier dans les infobox et autre modèles, mais c'est très difficile. Le Projet:Charte graphique manque d'autorité hélas. Du coup, je me suis d'avantage focalisé sur les briques V2 pour infobox en me disant que ce serait plus simple ensuite d'y introduire des chartes graphiques... D'après moi pour le modèle {{Charte de couleur}} , ce serait plus évident de le modifier de la façon suivante, si on veut d'avantage coller aux recommandations de la page Projet:Charte_graphique/Domaine_géographique :

<noinclude>{{Doc modèle|parser=oui}}</noinclude><includeonly>#{{#switch:{{lc:{{{1}}}}}
  | couleur forte           = {{#switch:{{lc:{{{2}}}}}
    | localité         = ffffbb
    | commune          = ddffdd
    | intercommunalité = ffe2bf
    | canton           = ece5ca
    | arrondissement   = e1e1e1
    | département      = f6f3dd
    | région           = bbdefd
    | défaut           = e1e1e1
    | #default         = e1e1e1
  }}
  | couleur faible = {{#switch:{{lc:{{{2}}}}}
    | localité         = <à définir>
    | commune          = f3fff3
    | intercommunalité = <à définir>
    | canton           = faf9ec
    | arrondissement   = f1f1f1
    | département      = f6f3dd
    | région           = f2f6fe
    | défaut           = e1e1e1
    | #default         = e1e1e1
  }}
  | #default           = e1e1e1
}}</includeonly>

Il vaut mieux parler de couleur "forte" ou "faible". Outre les intercommunalité, il y a aussi les localités (hameaux, villages, lieux-dits et écarts) qui sont apparus dans le jeu et où le jaune s'est imposé. amicalement--Wikialine (d) 5 octobre 2011 à 00:10 (CEST)

Je n'ai pas le temps de te faire une réponse complète, mais il faudra tenir compte du fait que ce modèle est déjà utilisé, et qu'il serait intéressant qu'il puisse être étendu à d'autres domaines que la "géographie administrative".--Juju2004 (d) 5 octobre 2011 à 08:47 (CEST)

Ce qui est sûre c'est que l'on n'est pas obliger d'utiliser ce genre de modèle immédiatement. On peut aisément l'ajouter après coup, ça reste de la mécanique interne invisible pour les rédacteurs et les lecteurs de WP. amicalement--Wikialine (d) 5 octobre 2011 à 14:55 (CEST)

 

Penser au modèle {{Charte de couleur}}--Juju2004 (d) 18 octobre 2011 à 10:04 (CEST)

Graphique d'évolution de la population

discussion temporairement close (n'hésitez pas à la rouvrir)

Pour ce qui est du graphe, je suis allé demander à l'atelier accessibilité s'il vaut mieux une timeline ou le construire avec un tableau. Les timelines sont assez moches à mon goût, mais je crois que ce sera mieux que d'essayer de dessiner avec du HTML (pas prévu pour).--Juju2004 (d) 2 octobre 2011 à 22:25 (CEST)

J'avais pensé à l'usage d'une timeline puis je me suis ravisé car pour mettre à jour une timeline, il faut réactualiser la page qui l'accueil... J'avoue avoir une préférence pour le bon vieux script HTML qui a fait ses preuves. Mais bon, si tu veux tenter l'usage des timeline alors ok, essayons de les utiliser. Pour moi le plus important c'est que le graphique se génère tout seul sur l'article, c'est la règle ultime auquel je ne veux pas déroger.--Wikialine (d) 3 octobre 2011 à 12:59 (CEST)

Sur l'exigence que le graphique se génère tout seul, c'est évident : il doit suffire d'introduire le modèle et le reste doit suivre. Je vais me renseigner sur les timelines et voir ce qui est possible. Dans l'immédiat, j'attends les réponses de l'Atelier accessibilité et il me paraît difficile de passer outre leur avis sans très bonne raison. On verra ce qu'ils disent.--Juju2004 (d) 3 octobre 2011 à 13:54 (CEST)

Avant les timelines, c'était le mal en terme d'accessibilité, puis ensuite plus et actuellement, on nous dit que ce n'est pas génial mais que ça reste acceptable. En terme d'accessibilité, il faut être franc ni le html ni les timeline sont entièrement accessibles. Pour moi le critère a été d'utilisé le HTML car les timeline ne peuvent pas se mettre à jour sans une réactualisation et les solutions, que j'ai trouvé pour contourner ce problème tout en conservant un script de timeline, ne sont pas satisfaisantes. Fais tes essais pour te faire une idée. Quand à l'atelier accessibilité, il n'est pas infaillible. Si tu leur parle pixel alors on te répondra non accessible pourtant WP utilise des valeur en px. Si tu leur parle js alors on te répondra non accessible pourtant WP utilise des script js. Lorsque j'ai créé le js pour le passage des cartes de géolocalisation (carte physique à carte administrative et inversement...) dans les infobox, j'ai du bataillé et au final ça à abouti malgré les blocages que j'ai subit. Et encore tout ces blocages ont été très dommageable car le js n'a pas pu évoluer comme c'était prévu (absence de zoommage, de passage de cartes plus petite à plus grande du genre Monde > France > Région > Département et inversement ...). Mais bon WP évolu et peut être que depuis les Timeline sont devenu plus souple dans leur utilisation. C'est pourquoi, je suis amplement d'accord avec toi pour étudier la question, surtout que ça nous simplifierai la tache au niveau d ela programmation. amicalement--Wikialine (d) 3 octobre 2011 à 23:47 (CEST)

Je me doute bien que tout ce qui est de nature graphique n'est pas évident en termes d'accessibilité. L'avantage de timeline est qu'on a juste une balise img, et pas un faux tableau et des dizaines de div qui traînent. Si tu appelles "réactualisation" le fait d'avoir à purger le cache après modification des données, je pense que ce sera pareil avec du HTML (il y a aussi la job queue qui s'en charge au fur et à mesure). Dis-moi ce qui pose problème avec un modèle comme {{Relevé hydrologique}}.

En attendant, voici l'approche que je propose :

1. créer un modèle pour histogramme, très semblable dans sa syntaxe à {{Démographie2}} (bien sûr, les paramètres seront différents) ;
2. le modèle {{Graphique Population}} ferait appel à ce premier modèle, avec le même lien "Voir base de données" que pour le tableau ;
3. dans les pages "Données population/<commune>/évolution" (également utilisées par le tableau), ajouter un lien vers les données brutes sous forme de tableau vertical basique : cela devrait régler le problème d'accessibilité. Ce tableau serait générés par le bot, par exemple dans une sous-page "Données population/<commune>/évolution/tableau".--Juju2004 (d) 4 octobre 2011 à 09:28 (CEST)

Pour le moment niveau graphique, on ne doit rien s'interdire et multiplier les essais. Perso, si l'on pouvait utiliser les timelines se serait mieux. Reste à développer des essais de ce coté là et si ça n'aboutit pas alors on se rabattra sur le html ou autre moyen équivalent. Ton idées d'histogrammes en prenant exemples sur Démographie2..., je dis oui tentons le coup, ça me paraît bien. Par contre je vais passer un peu du coq à l'âne, il faudrait que l'on rediscute de la structure des modèles Données, mais pour ça il vaut mieux ouvrir un autre sujet (voir ci-dessous) afin de ne pas mélanger les débats entre le graphique et la structure des modèles Données. Pour le tableau vertical basique, ça ne sert pas à grand chose à mon sens. Epargne toi du temps, l'important c'est que les rédacteur sachent où sont les informations, on peut à la rigueur renforcer l'aspect pédagogique dans la documentation des modèles données. Par ailleurs, il faut éviter de multiplier les sous-pages, beaucoup de wikipédiens y sont opposés. Restons sobre de ce coté là, c'est préférable, crois moi. amicalement--Wikialine (d) 4 octobre 2011 à 14:46 (CEST)

Toujours dans l'ordre :

• évidemment ok pour les essais perso ;
• d'ailleurs, j'en ai ajouté deux avec timeline sur la page de test  ;
• je reviens : le tableau vertical basique, ce serait à charge du bot, donc pour plus tard. Mais ça me paraît important pour l'accessibilité ;
• des wikipédiens opposés au sous-pages ? ceux qui refusent de lire la documentation des modèles lorsqu'elle s'y trouve ? (re-) Qu'ils fassent une demande pour que les sous-pages ne soient plus accessibles dans l'espace modèle ! Plus sérieusement, je préfère cacher la mécanique dans une sous-page et laisser les contributeurs se concentrer sur les articles. Si certains ne sont pas contents, ils pourront avancer leurs arguments et on verra si c'est recevable.--Juju2004 (d) 4 octobre 2011 à 17:54 (CEST)

J'ai eu quelques voyants rouges au niveau de la création de sous pages en grande quantité, ici ou là dans quelques discussions. C'est pourquoi, j'aurai préféré ne pas compromettre l'approbation du système juste pour une histoire de sous-pages, mais ça reste de simples craintes. Si tu tiens absolument à travailler avec des successions de sous-pages, moi ça me va quand même, c'est juste qu'il faudra bien bétonner le système pour parer toutes oppositions de chapelle. En attendant revenons en à nos graphiques, tes premiers essais semblent prometteurs et si l'on décide de ce plonger à fond dans les sous-pages alors l'usage des timelines ne devrait plus poser de problèmes dans ce contexte. On verra ce que ça donne au final.amicalement--Wikialine (d) 4 octobre 2011 à 21:22 (CEST)

Pour ce qui est des graphiques, ça commence à fonctionner. A noter qu'on peut éventuellement rajouter également les sources, et que j'ai eu besoin d'une nouvelle donnée sur l'évolution de la population : "nombre" qui contient le nombre d'années/population dans le graphique. Le bot ne devrait pas avoir de difficulté à indiquer cette information.--Juju2004 (d) 5 octobre 2011 à 23:30 (CEST)

Aujourd'hui ça a été boulot boulot , je n'ai pas pu aller sur WP, j'arrive seulement maintenant sur le site. Je suis contente que tu ais pu avancé sur le projet. --Wikialine (d) 6 octobre 2011 à 20:28 (CEST)

Quelques points à étudier :

1. Titre : On peut mettre "Histogramme sur l'évolution démographique", ce serait plus générique quelque soit la charte et juste avant le graphique dans les articles il y a aura le tableau qui indique déjà qu'il s'agit de la démographie de telle ou telle collectivité (région, département, commune...). (Voir l'exemple que j'ai mis dans la page test)
2. Espace entre les colonnes : Il faut prévoir des espaces entre les colonnes qui respecte la durée en nombre d'année. Actuellement notre graphique met un espace identique entre chaque date. Les membres du CDF font de plus en plus attention à bien prendre en compte ce probème. (voir exemple sur cet article Adq Antony#Évolution démographique)
3. Sources, on peut se contenter d'ajouter seulement dans le modèles l'indication du genre "Sources - base Cassini de l'EHESS et Insee", en bas à gauche sur la même ligne que le lien "Voir base de données". En effet, les sources précises, avec liens et tout et tout, sont déjà ajoutées dans le tableau, ça éviterait des ref doublons en bas de page... C'est ce que j'avais appliqué en créant la première version du graphique et c'est ce que les membres du projet CDF appliquent également dans les articles la plupart du temps.

Voilà quelques détails donc à améliorer. amicalement--Wikialine (d) 6 octobre 2011 à 23:03 (CEST)

 Fait.--Juju2004 (d) 7 octobre 2011 à 16:46 (CEST)

C'est de l'excellent travail Juju2004. Quelques détails restant à voir éventuellement :

1. Mettre sur la même ligne le lien 'Voir base de données" et le contenu du paramètre des sources (voir dans la page test mon essai) avec un fond blanc, on a l'impression d'avoir un fort espace vide entre les dates et les sources...
2. Dans un soucis d'homogénéité des modèles, réduire la taille des sources en prenant exemple sur la taille des sources du tableau qui est plus petite. Ce changement de taille est appréciable car il permet de distinguer en un coup d'œil le contenu de l'article de ses sources.

Voilà c'est les dernières observations que j'ai trouvé autrement le reste est parfait, tout cela me parait cohérent. amicalement--Wikialine (d) 8 octobre 2011 à 01:38 (CEST)

Je suis en train de travailler sur ces modifications. J'ai vu que tu avais réussi à faire marcher une version HTML, ce qui est une très bonne nouvelle au cas où la balance pencherait finalement pour ce choix.--Juju2004 (d) 8 octobre 2011 à 14:09 (CEST)

La version HTML doit rester un simple plan B, la timeline doit être privilégié. L'exemple que j'ai mis à des colonnes erronées, je n'ai pas pris le temps de corriger les erreurs dans le script. Je voulais que ça soit un peu plus propre sur la page de test en retirant les messages d'erreurs provoqués avant cela par le changement de nom des modèles de données. L'essentiel c'est d'avoir un exemple et désormais un panel complet de ce qui est faisable en matière de graphiques. Finalisons le graphique version timeline, c'est le plus important. amicalement--Wikialine (d) 8 octobre 2011 à 22:41 (CEST)

J'ai vu que tu avais adapté les couleurs : parfait. Je ne renonce pas à mettre en place une version améliorée de {{Charte de couleur}} et je m'occupe de l'écart entre les sources et le tableau.--Juju2004 (d) 10 octobre 2011 à 08:46 (CEST)

PS. pas de réponse sur l'Atelier accessibilité ni sur le Bistro : on va rester sur la timeline.--Juju2004 (d) 10 octobre 2011 à 08:48 (CEST)

Au niveau charte des couleurs, j'ai préféré mettre des couleurs standards déjà employées dans les articles, pour les exemples c'est préférable. Les membres du CDF et autres projets ont déjà des standards. Par contre, je t'approuve totalement au niveau du modèle {{Charte de couleur}}, il serait souhaitable de l'inclure prochainement dans nos modèles. ça sera un grand pas vers l'harmonisation des codes couleurs dans les chartes. Ce genre de modèle peut s'ajouter après coup ça ne posera pas problème, c'est de la mécanique interne au modèle. Je suis d'accord avec toi, continuons avec la timeline. amicalement--Wikialine (d) 10 octobre 2011 à 17:27 (CEST)

J'ai inséré les données dans la timeline, comme tu peux le voir sur la page de démonstration. Je pense que c'est plutôt pas mal, dans la mesure où le graphique ne peut pas se balader sans les infos sur la source, ce qui est un avantage pour l'autorisation que nous souhaitons de la part de l'INSEE et de l'EHESS. Dis-moi ce que tu en penses.--Juju2004 (d) 10 octobre 2011 à 22:28 (CEST)

C'est parfait, rien à redire. amicalement--Wikialine (d) 11 octobre 2011 à 00:51 (CEST)

 

Penser à la remarque de Roland : "Concernant le graphique, j'avais pour ma part travaillé sur les pas de l'échelle afin de rendre le graphique agréable à l'oeil. J'avais retenu comme principe de ne pas avoir plus de 8 lignes principales et les lignes secondaires (interlignes) se déduisaient selon le nombre de ligne sprincipales (en général soit 5, soit 2). J'y reviendrai. Actuellement l'exemple d'Antony présente 6 lignes principales et 10 interlignes, cela parait un peu chargé."--Juju2004 (d) 18 octobre 2011 à 10:06 (CEST)

Débats autres

Enfin !

Bonjour à vous eux. J'écris « Enfin ! » car il me semble que cela doit faire près de cinq ans que nous discutons de ce projet de bot avec Wikialine. Entre-temps, il y a eu le magnifique travail fait pour unifier l'Infobox et le script Démographie2, merci encore à Roland45 pour le temps passé. Un à Juju pour avoir choisi la commune, origine de mon pseudo, et bravo pour tout ! Un regret toutefois, ne pourriez-vous pas modifier la couleur de l'histogramme et reprendre les couleurs qui avaient été retenues, à savoir vert pour les bâtons et fond blanc ? Restera à traiter ensuite les cas particuliers (derniers recensements) comme l'a fait Roland45 dans son script (avec le texte qui va bien pour expliquer). Cordialement. AntonyB (d) 8 octobre 2011 à 16:49 (CEST)

Je me rends compte que j'ai été un peu imprécis quant au degré d'avancement : même si ça prend forme, rien n'est définitif :

• le bot n'est pas encore en marche (à mon avis, il y aura pas mal de travail de ce côté là, mais je n'ai aucun doute sur la possibilité d'en venir à bout) ;
• le modèle d'histogramme n'est pas encore choisi (timeline ou HTML : les deux fonctionnent) ;
• on peut y ajouter les problèmes du type de celui soulevé par Père Igor ci-dessous et tous les autres auxquels on n'a pas encore pensé.

Mais avant de continuer à avancer sur tous ces points, il fallait prendre les avis du projet CDF. Donc toutes les remarques sont les bienvenues. Comme j'arrive très tardivement sur ce projet, je veux bien que tu m'indiques l'endroit où les couleurs ont été choisies, que je puisse adapter le modèle utilisant timeline.--Juju2004 (d) 8 octobre 2011 à 19:38 (CEST)

Bonsoir François, j'ai fait quelques retouches au niveau de la cosmétique du tableau et du graphique pour être plus proche des habitudes des membres du projet CDF. amicalement--Wikialine (d) 8 octobre 2011 à 23:39 (CEST)

Bonjour à tous. Je me joins à cette valeureuse équipe pour apporter mon humble contribution, ayant pas mal travaillé sur le sujet avec la création du script Excel qui génère textes, tableaux et graphiques. Je constate d'abord que l'ambition actuelle est de créer des modèles pour générer tableaux et graphiques, sans générer de textes descriptifs. Cela me parait réducteur, car si un article ne comporte pas de section démographie renseignée, le contributeur qui ajoutera le modèle de tableau ou de graphique ne prendra pas le temps de faire le texte qui de toute façon sera obsolète plus tard. Certes ce texte est généré par un modèle du type "résumé introductif" sur lequel le contributeur ne peut pas intervenir, mais il peut en tout état de cause ajouter du texte après si il le souhaite. Je pense que dès maintenant il faut avoir en perspective de générer un texte introductif à chaque section, même si on commence par texte et tableaux, car il sera difficle de revenir sur la Bdd si on n'y a pas pensé avant.

J'attire aussi l'attention sur trois aspects sources de complexité :

• la source de données doit comporter un grand nombre de données (au-delà des simples nom - type - ann - popn - max - nombre - sourcei) si on veut par exemple générer les textes et on ne pourra pas développer le modèle avant que cette base soit stabilisée (cf pb du résumé intro, même si il n'est âs développé ds l'immédiat);
• la création des modèles de données de populations ne pourra selon mon point de vue pas se faire sans passer par une intervention manuelle via un script Excel pour récupérer les données avant 1962 (Cassini) (script qui existe déjà);
• les modèles pour générer les textes doivent comporter un certain nombre de tests, car les textes sont adaptés à chaque commune.

Par ailleurs j'ai rapidement parcouru la page et ai vu que je ne travaille pas à partir des mêmes sources. Je vais apporter des infos là-dessus.Roland45 (d) 13 octobre 2011 à 07:37 (CEST)

Bonjour Roland, je suis contente que tu sois là. J'ai commencé à te briefer plus haut dans ton autre message sur certains détails techniques qui ont évolué depuis la dernière fois. Concernant le choix de travail exclusif sur le tableau et le graphique, c'est dans un soucis de clareté des débats et il s'agit là d'une première étape. L'objectif actuel et le plus urgent est la mise en place d'un système globale de mise à jour des données, avec comme première données ajoutées celles des recensements (il en viendra d'autres par la suite). Pour le moment on a bien avancé sur le choix de structure et de nom des modèles de données qui permet de laisser la porte ouverte à toutes sortes de nouvelles données (non plus des données uniquement démographiques...). Comme toi je suis très favorable à la mise en place de modèles plus génériques (l'harmonisation des articles et des modèles est mon combat depuis toujours) dans les articles. Il va de soit que mettre des textes introductifs serait une bonne chose. Techniquement c'est faisable. Sauf que pour le moment on a plusieurs problèmes (qui ne sont pas insurmontables loin de là).

1. Le premier problème c'est de savoir que veulent les membres du CDF, sont-ils d'accord pour mettre en place un modèles de section de démographie qui mettrait automatiquement des textes, des graphiques (évolutions démographiques, pyramides des ages...), des tableaux... Personnellement j'y suis totalement favorable, j'ai d'ailleurs créé le modèle {{Section démographie d'article de commune de France}} et mis un exemple sur la page Projet:Communes de France/Mise à jour automatique des données démographiques/Antony
2. Autre problème l'aspect légale, on est encore un peu dans le flou de ce coté là. Déjà juste la prise des données de recensement peut poser problème alors télécharger d'autres données pour les mettre sur WP cela peut être un soucis. Il faudrait qu'un membre du projet se charge de cette question juridique dans le détail.

Pour le 1er problème ça peut se régler en avançant progressivement j'en suis convaincu et techniquement ça nous donne du temps pour ajouter progressivement toutes les données, car à chaque fois il va falloir programmer le bot. Pour le second problème, je suis dans le flou, il nous faut un membre qui se charge en urgence de ce problème car si légalement on e pas prendre certaines données alors la messe est dite. Autre point important que je voulais discuter avec toi Roland, voilà les sources que l'on a pu rassembler pour le moment Projet:Communes de France/Mise à jour automatique des données démographiques#L'origine des données, je sais que tu as pas mal plancher sur ce domaine en travaillant sur tes tables excels... Si tu connais d'autres sources intéressantes, n'hésites pas à les communiquer. Autre point que je tenais à soulever, comme toi je penses qu'effectivement il y aura surement besoin passer par une intervention manuelle ici ou là. On est qu'au commencement, c'est pourquoi restons concentrer sur la première étape à savoir mise en place du système en créant les modèles de données et en y ajoutant les premières données. Et si c'est une réussite, alors tout est possible on va pouvoir imaginer ajouter d'autres données démographiques, mais je verrais bien aussi des données politiques (nom des maires car là aussi c'est long, il faut à chaque élection reprendre les articles...), données climatiques éventuellement... Enfin bref, je m'enflamme déjà. Voilà Roland tu sais tous, à présent à nous de réussir notre examen d'entrée en ne ratant pas l'ajout des données démographiques. P.S : Si tu tiens vraiment à commencer à travailler sur les textes automatisés, j'y suis pas opposé pour autant. On peut toujours commencer à plancher sur un texte généralise qui sera progressivement modifié au fils des nouvelles données disponibles dans les modèles données. Déjà juste avec les données de recensements, on devrait pouvoir imaginer des textes qui diraient des trucs du genre "La commune a eu sa plus forte population en 1900 avec 558585 habitant en revanche, en 2002, sa population a été la plus faible avec 10 habitants", il faudrait imaginer des scripts qui compare les données... amicalement--Wikialine (d) 13 octobre 2011 à 15:21 (CEST)

Bonjour Aline, juste un petit mot pour te dire que le texte rédigé automatiquement l'est aujourd'hui par le script de notre si cher Roland (même s'il y reste quelques anomalies qui sont corrigées progressivement). Cordialement. AntonyB (d) 13 octobre 2011 à 20:53 (CEST)

Je n'ai pas été très présente durant la période de diffusion du script de Roland... Communiques moi ce texte afin que je l'ajoute en exemple dans le modèle {{Section démographie d'article de commune de France}}. C'est une bonne chose qu'un texte introductif qui fasse consensus existe déjà. amicalement--Wikialine (d) 13 octobre 2011 à 22:00 (CEST)

Bonjour Roland et bienvenue sur cette reprise d'un projet que, j'ai pu constater, tu connais bien. Pour faire court : nous avons réduit les ambitions (immédiates) pour arriver à quelque chose. C'est-à-dire que dans un premier temps, l'idée est de pouvoir générer automatiquement le tableau démographique et le graphique correspondant. Cela pose déjà des problèmes redoutables : la programmation du bot, l'autorisation du bot et l'aspect légal, entre autres. Mais les choix actuels ne limitent pas les possibilités futures : il sera possible d'intégrer plus de données à l'avenir, ou d'utiliser différentes pages de données. C'est à voir plus tard. Si on essaie de tout faire d'un coup, on va se retrouver face à un mur et on va se décourager.

Pour ce qui est de l'aspect légal, je crois qu'on peut dans un premier temps l'ignorer en mettant en place une solution utilisant les données des communes commençant par une lettre. (J'ai proposé "S" en raison de sa fréquence dans la langue française.) C'est parfaitement légal et ça donnerait un exemple de ce qu'on peut faire avant de demander une autorisation à l'INSEE ou à l'EHESS.

Enfin, sur ton script Excel, je ne vois pas exactement ce qu'il fait par rapport à Cassini : va-t-il récupérer directement les données en ligne ? Il faudrait que tu détailles un peu pour qu'on puisse se faire une idée.--Juju2004 (d) 13 octobre 2011 à 21:06 (CEST)

Bonjour à tous deux. OK pour ne travailler dans un premier temps que sur les tableaux et graphiques. Les données avant 1962 sont effectivement le point d'achoppement du système. Il n'existe pas en ligne de base de données qui donne toutes ces données pour toutes les communes. Peut-être que l'EHESS accepterait de les communiquer sous une forme ou une autre, mais je doute. La manip consiste simplement à faire une sélection écran du tableau d'une commune dans le site de l'EHESS (Cassini) puis copier/ coller dans le tableau, le script fait le reste en produisant clé en main le tout. Mais attention il y a des petits pièges, suivant les régions, départements ou commune (Nice), certaines dates de recensement ne sont pas les mêmes que pour les autres communes. Il faut donc faire des tests.

Concernant le graphique, j'avais pour ma part travaillé sur les pas de l'échelle afin de rendre le graphique agréable à l'oeil. J'avais retenu comme principe de ne pas avoir plus de 8 lignes principales et les lignes secondaires (interlignes) se déduisaient selon le nombre de ligne sprincipales (en général soit 5, soit 2). J'y reviendrai. Actuellement l'exemple d'Antony présente 6 lignes principales et 10 interlignes, cela parait un peu chargé. Bon, je m'absente. A +.Roland45 (d) 13 octobre 2011 à 22:32 (CEST)

Bonjour à tous. Pour Wikialine et Juju : pour vous informer sur le rendu du script que nous utilisons systématiquement depuis longtemps maintenant pour les articles de communes (cf. le lien donné ici), il vous suffit de jeter un coup d’œil aux derniers articles « désébauchés » : par exemple Roquebrune-sur-Argens (cas d'une commune de plus de 10 000 habitants) ou Terre-Natale (cas d'une commune de moins de 10 000 habitants), puisque le texte ajouté automatiquement diffère suivant le cas. Cordialement. AntonyB (d) 13 octobre 2011 à 23:42 (CEST)

Merci pour le lien sur le script qui est très bien fait. Mais je crois qu'il faut distinguer deux choses : le noyau dur du projet, qui consiste à automatiser au maximum un domaine restreint (les tableaux et les graphiques), et un domaine plus étendu mais semi-automatisé (copier-coller à l'entrée et à la sortie) que le script de Roland semble gérer tout à fait bien. Je propose donc qu'on se limite dans les discussions sur cette page (pour l'instant) à l'automatisation du noyau dur parce qu'il y a encore beaucoup de travail à faire. La question clé pour l'instant est : où chercher quelles données ? Il y a un tableau à remplir.

Pour le graphique, des modifications sont possibles (y compris après l'importation des données), mais je me concentre pour l'instant sur la programmation du bot.--Juju2004 (d) 14 octobre 2011 à 10:32 (CEST)

J'ai ajouté ci-dessus et dans la page projet le lien vers la base sur laquelle je travaille, il s'agit du tableau Excel "Évolution et structure de la population" qui permet de récupérer toutes les informations postérieures à 1962 nécessaires pour construire les tableaux et graphiques (évolution de la population et pyramides des âges) : le tableau s'appelle BTX_CC_POP_2008.xls et se trouve sur la ligne "Évolution et structure de la population" de cette page. Mais attention, on ne coupera pas à travailler sur une base dérivée pour avoir certains indicateurs déduits du tableau.Roland45 (d) 14 octobre 2011 à 13:34 (CEST)

Autant pour moi, je viens de voir que tu as mis l'accès direct au-dit tableau. Probablement que le premier fichier (france2011.txt) n'est pas non plus nécessaire.Roland45 (d) 14 octobre 2011 à 13:39 (CEST)

Pas de problème. Je préfère garder pour l'instant le premier fichier sous la main au cas où, mais il est probable qu'il va disparaître par la suite.--Juju2004 (d) 14 octobre 2011 à 15:47 (CEST)

Nombre de communes

Il est dit dans la page projet que le domaine couvre "les articles sur les 36 828 communes de France". Or le tableau BTX_CC_POP_2008.xls comporte 36682 lignes donc 36682 communes. 146 communes d'écart, cela fait quand même beaucoup. Il va falloir voir d'où vient cet écart, ce ne peut pas être uniquement des communes qui ont disparu après fusion. Quelle est la source de ce 36828 ?Roland45 (d) 14 octobre 2011 à 18:10 (CEST)

Je ne sais plus dans quelle région c'est, mais j'ai entend parler dernièrement d'une fusion de 4 communes en une seule. Les fusions de communes fausses le nombre de commune totale. Il y a aussi les dom-tom qui parfois... Toujours est-il que le plus simple serait de créer une page de rapport du bot. Après usage du bot, on pourra consulter son rapport qui nous rapportera les articles qui n'ont pas pu être modifié par exemple ce qui pourra signifier un changement de code insee, un changement de nom de commune et donc du nom de l'article... Voilà un premier moyen pour contrecarrer ce problème. amicalement--Wikialine (d) 14 octobre 2011 à 21:30 (CEST)

Bonjour. Rassurez-vous, il n'y a rien de mystérieux derrière ce nombre, donnée en effet éminemment instable, mais pas à ce point-là tout de même. Au recensement de 1906, on dénombrait 36 221 communes. Au recensement de 1999, on dénombrait 36 565 communes. Au 1^er janvier 2008, le nombre de communes était 36 678, au 1^er mars il était de 36 683. Au 1^er janvier 2009, le nombre de communes était 36 679. Au 1^er janvier 2010, le nombre de communes était 36 682. Toutes ces évolutions sont expliquées avec un grand luxe de détail dans le document de base que je vous conseille de connaître. Cordialement. AntonyB (d) 14 octobre 2011 à 22:33 (CEST)

Tu es sévère avec nous, @AntonyB ... 324 pages pour le document de base, c'est assez indigeste!!Roland45 (d) 15 octobre 2011 à 08:44 (CEST)

Bonjour. Désolé de m'être mal fait comprendre parce que bien au contraire je voulais aider l'équipe. Ce document est simplement à « connaître » comme je l'ai écrit, c'est-à-dire qu'il faut avoir « connaissance » de son existence et le moment venu, lorsqu'on cherche une information relative à l'évolution des communes, il suffit tout simplement de faire une recherche dans ce document. Mais bien sûr il n'est pas à lire, mais simplement il est utile d'en « connaître » l'existence. Désolé encore ! Cordialement. AntonyB (d) 15 octobre 2011 à 09:26 (CEST)

Faite gaffe AntonyB prépare une interro surprise à l'intention de tout les membres du projet --Superjuju10 ^{Auboisement à votre écoute} 15 octobre 2011 à 19:01 (CEST)

Bonjour François, j'ai ajouté le cog dans la page Projet:Communes de France/Mise à jour automatique des données démographiques#Aspects techniques : traitement des erreurs. Effectivement ce document nous sera utile lorsque le bot sera en place. Le traitement des erreurs de mise à jour va être inéluctable en raison de l'évolution du nombre de commune... amicalement--Wikialine (d) 15 octobre 2011 à 14:44 (CEST)

Sinon pour rester sérieux, étant donné que l'INSEE publie chaque début d'année la mise à jour des populations légales, quels seront les conséquences avec ces modèles ? La mise à jour se fera par bot ou il faudra comme précédemment ajouter les données manuellement ? --Superjuju10 ^{Auboisement à votre écoute} 15 octobre 2011 à 19:01 (CEST)

C'est précisment l'objet du bot, de mettre à jour en une seule fois toutes les pages de bases de données de populations associées à chaque article de commune. Un seul passage et tout est mis à jour. La difficulté actuelle est de créer ces bases, particulièrement en ce qui concerne les données antérieures à 1962 (Cassini).Roland45 (d) 15 octobre 2011 à 19:12 (CEST)

Mise en place partielle du système

Bonjour, en ce moment je ne peux pas trop intervenir sur WP par manque de disponibilité. Pour autant, j'espère que tous va bien. je vais essayer de trouver un moment pour me pencher sur la programmation du bot. En attendant, on pourrait à la rigueur songer à 1 plan B histoire de simplifier la programmation du bot. On pourrait (avec tous les membres du projet CDF) mettre en place manuellement les Modèles de données démographiques par communes (on a déjà fait plus compliqué, je sais que c'est faisable), département par département en créant une liste comme on le fait actuellement... et donc en travaillant à notre rythme suivant nos disponibilités. En procédant ainsi, on se simplifie la tache au niveau de la programmation du bot. Cela reste 1 plan B histoire de contourner en parti les difficultés de programmation du bot.amicalement--Wikialine (d) 23 novembre 2011 à 22:10 (CET)

Je ne pense pas que mettre en place les modèles de données, alors même que la structure des données n'est pas stabilisée et qu'on ne sait pas si le bot est faisable ou non, soit une bonne idée. Je suggère que l'on attende qu'une première version soit testée sur les modèles de données existants. On a tout le temps. J'en profite d'ailleurs pour signaler un pb qui, me semble-t-il, n'est pas résolu : comment mettre à jour les données de l'Insee dans Infobox ? Le bot le permettra-t-il ?Roland45 (d) 30 novembre 2011 à 19:35 (CET)

Au niveau de l'infobox pas de soucis à avoir ça devrait aller. J'avais donné un exemple lors de la première version du système afin de démontrer la faisabilité. Je m'y collerai le moment venu pour l'adapter à la nouvelle structure des modèles de données... amicalement--Wikialine (d) 2 décembre 2011 à 22:00 (CET)

Mise a jour 2009 avant grand travaux ?

Bonjour à tous ! Conduit céans sur les bons conseils de Wikialine, je me propose de me joindre à vous pour des discussions et développement logiciel concernant la mise à jour automatique des données. Néanmois, en marge de ce travail de longue halène, ne serait-il pas opportun de procéder à une mise à jour automatisée pour légère (court terme) des données 2009, laissant ensuite l'année tranquille pour travailler sur le projet ? Suite à une proposition initiale, puis aux disussions liées, je me propose de faire tourner un bot qui effectuerai les modification suivante sur les articles de communes qu'il croise :

Modèle démographique	Action
{{Infobox Commune de France}}	mise à jour
{{Infobox Communes de France}}	correction de la redirection, mise à jour

La mise à jour de l'infobox consiste en la récupération du code INSEE présent, sa validation sur le site de l'INSEE et la récupération de la valeur 2009 sur ce même site. L'infobox est ensuite modifiée en sans et date-sans. Ensuite, la valeur 2009 est inséré dans un modèle de démographie si et seulement si il est trouvé dans l'article, comme suit :

Modèle démographique	Action
{{Démographie2}}	mise à jour
{{Démographie}}	conversion vers {{Démographie2}} (et mise à jour)
{{DemogAL}}
{{DemogFR}}
{{DemogNS}}
{{DemogOM}}	une seule commune concernée, traitement manuel
{{DemogFranceAR}}	non utilisé, non traité
{{Démographie France}}

Enfin, comme 2006 doit toujours être présent, et 2009 est la dernière en date, quelques dates (2007, 2008) sont supprimées, en fonction des dates de recensements de l'INSEE.

Année de recensement indiquée	Dernier recensement réel	Années à supprimer (si trouvées)
Chaque année	toutes	aucune 2007, 2008
2012	2007	2008
2013	2008	2007
2014	2009	2007, 2008
2015	-
2016	-

Il s'agit d'une opération de traitement léger (une simple mise à jour 2009), pour avoir rapidement et simplement des données à jour. Ça ne rentre pas dans le projet de structuration de modèle de données sus-cités ni ne le nie, c'est un simple à-coté, avant de me consacrer pleinement au projet long terme d'automatisation.

Qu'en pensez vous ? -- Erkethan (d) 6 janvier 2012 à 12:32 (CET)

Bonjour, C'est effectivement OK. Pour les communes de + de 10 000 habitants, probablement que lorsque l'on aura atteint un cycle de 5 ans après 2006, on pourra procéder par convention à la suppression des années entre 2006 et 2011 et ainsi de suite.Roland45 (d) 6 janvier 2012 à 18:44 (CET)

Pour les communes de + de 10 000 habitants, je pense qu'il ne faut conserver, pour l'instant, que 2006 et 2009, puisque les communes en question ne sont jamais recensées entièrement mais que seulement 20 % de la commune est recensé chaque année. Père Igor (d) 8 janvier 2012 à 16:47 (CET)

Le bot concerné est prêt ! Les simulations ont été réalisées sans écritures dans l'encyclopédie, et vérifiées manuellement. A votre avis, est-ce le bon moment pour lancer la procédure de demande de Bot-flag, ou dois-je procéder à quelques écritures réelles avant ? -- Erkethan (d) 10 janvier 2012 à 23:23 (CET)

Tu peux tester sur la Charente-Maritime si tu le souhaites ! (c'est un des projets suivi par assez de contributeurs pour repérer d'éventuelles boulettes, mais il y a bien d'autres départements tout aussi actifs !) Très bonne initiative en tout cas ! — Droop ^[blabla] 10 janvier 2012 à 23:43 (CET)

Bonjour. Que voilà une bonne nouvelle ! Pour satisfaire tout le monde, je te propose de mettre très vite un message dans la PDD du Projet et sauf avis contraire de la communauté de commencer par le département de la Charente-maritime par exemple. Si tout se passe bien, je te propose de poursuivre. J'aimerais bien que le bot traite les communes franciliennes; j'ai déjà fait le 92 (on pourra ainsi montrer que le bot peut traiter des communes déjà à jour) mais il y a quelques départements très en retard, cela fera du bien à l'encyclopédie ! Merci encore, cordialement AntonyB (d) 11 janvier 2012 à 09:58 (CET)

Où en est on aujourd'hui ?

Bonjour,

J'ouvre une nouvelle section car je souhaiterai apporter mon aide, et le faire de façon la plus constructive possible. Pour cela, j'aurai besoin de savoir où ce projet s'en est rendu et ce qu'il reste à faire. Si j'ai bien tout compris (corrigez-moi si je me trompe), on a une feuille de route en 4 points :

1. Récupération des données sources (et stockage dans une base intermédiaire) ;
2. Modélisation des "réceptacles" de ces données ;
3. Générations de ces modèles pour toute commune ;
4. Impacter les articles et infobox pour utiliser ces modèles.

Si et seulement si cette analyse est bonne, où en est-on, notamment pour les deux premiers points ? En ce qui concerne la récupération des données pour leur utilisation future, est-ce déjà rapatrié, à améliorer, ou à faire?

J'ai déjà croisé par mal d'info sur toutes les pages concernées, mais une photographie de l'instant présent m'aiderai beaucoup à me situer. Merci par avance de vos éclaircissements ! -- Erkethan (d) 20 janvier 2012 à 10:20 (CET)

Bonjour. Je pense que tu trouveras tout sur la page Discussion modèle:Section démographie d'article de commune de France. Bonne lecture, d'autant plus que ton nom y est cité comme aide potentielle ! Cordialement. AntonyB (d) 21 janvier 2012 à 23:44 (CET)

Concrètement, le système dans son ensemble repose sur l'usage de modèles de données, un par article de commune. Les articles sont mis à jour grâce à des modèles qui interprètent les informations mises dans les modèles de données. Après, pour ce qui est de la récupération des données, il faut utiliser un bot qui puisse se rendre sur des sites externes (Cassini et Insee), qui collecte les données pour les ajouter dans les modèles de données. Pour ce qui est du bot en lui même, j'avais présenté ici même mon bot expérimental Alinebot, qui récupérait les données sur le site de l'insee pour les ajouter sur les modèles de données (voir discussion sur cette page...). Pour mon bot, je n'avais pas eu besoin de créer de Bdd et de table. Un simple script en PHP suffisait. Dernièrement, au fil des débats ici, on a évoqué l'idée de créer une table (nom des communes, code commune, url...) afin de mettre sur pied un bot (un poids lourd cette fois car multitâche) capable dans un premier temps de créer les modèles de données et d'ajouter les données récupérées sur des sites externes. Pour le moment au niveau du bot, ça reste en attente. Mais j'ai commencé a réactiver mon bot de mon côté. J'ai commencé à l'actualiser mais avec ton arrivée, je l'ai remis de coté pour me concentrer sur les modèles wikipédiens (infobox, tableau, graphique...). J'ai également dernièrement mis en place un générateur semi-automatisé de modèles de donnée à l'adresse suivante http://wikialine.free-h.net/. Mais, il serait souhaitable de programmer le bot pour qu'il le fasse directement. J'ai consulté la page source d'une fiche Cassini, et il semble tout a fait possible de pouvoir récupérer les données démographiques. On peut y dégager une expression régulièrement et y travailler dessus à coup de regex et j'en passe... On a également commencé à plancher sur des textes introductifs, sur les droits, les besoins de mise en place d'une page de rapport du bot afin de prévenir des éventuels problèmes (changement de nom de commune, changement de code commune, ...). Voilà où on en est, plus ou moins. Amicalement--Wikialine (d) 22 janvier 2012 à 00:24 (CET)

OK, merci pour tous ces éclaircissements ! Je pense m'attaquer dans un premier temps au programme de remplissage automatique d'une base de donnée d'interface, qui contiendrait toutes les données démographiques exploitables pour toutes les années et communes, depuis Cassini et Insee. En devant résoudre bien sur les problèmes de noms qui ont changés (ou ne sont pas les mêmes sur WP), etc. Ça permettra d'avoir une source très facilement exploitable pour remplir les modèles de données ensuite. -- Erkethan (d) 22 janvier 2012 à 12:53 (CET)

INSEE -> Insee

Bonjour, vu le nombre d’occurrences de INSEE en majuscule dans l'article, il me semble utile de préciser que l'on écrit de préférence Insee : c'est à la fois ce qui est conseillé sur Wikipédia, dans le guide typographique de l'imprimerie nationale, et par l'Insee depuis environ trois ans, comme on peut le constater sur le site officiel (toutes les pages ne sont pas mises à jour, aussi trouve-t-on encore INSEE, mais dans les mentions légales on lit bel et bien Insee). Il m'arrive justement régulièrement de faire la correction dans les pages sur les communes, départements, cantons, etc. J'espère que la procédure de mise à jour automatique, et les bots qui s'en occupent déjà aujourd'hui, en tiendront compte. Nochnix (d) 28 mars 2012 à 10:37 (CEST)